Ces dernières années ont vu apparaître une technologie affichée comme révolutionnaire et permettant d’obtenir une réduction des investissements matériels considérable : la virtualisation système. Qui aujourd’hui n’a pas entendu parler des solutions de type VMWare ou encore Hyper-V, permettant sur un seul serveur physique d’exploiter plusieurs serveurs à part entière en optimisant au mieux l’utilisation des ressources matérielles souvent sous-exploitées sur les machines ? Le serveur devient alors un fichier et un espace mémoire précis, facilement manipulable par l’administrateur et offrant une souplesse de gestion et des fonctionnalités de haute disponibilité non négligeables.

Toutefois, ce concept n’est pas réellement novateur en soi, car déjà présent dans des domaines différents tels que les réseaux par exemple depuis des années, avec par exemple la notion de VLANs qui permet, au sein des mêmes équipements physiques, de définir des réseaux étanches entre eux. Le principe est donc le même, mais l’accompagnement réseau nécessaire à la mise en place de ce type de solutions d’un point de vue système est bien souvent trop négligé. Cette problématique résulte en effet de la combinaison de plusieurs facteurs, qui font que la mise au point d’une telle architecture peut rapidement complexifier les tâches d’administration et d’exploitation quotidiennes. 

L’organisation de nombreuses entreprises est telle qu’aujourd’hui les rôles et responsabilités des équipes IT sont bien identifiés, et leur périmètre très peu amovible. Cela reste relatif à la dimension de l’entreprise, mais à partir d’une certaine taille on retrouve bien souvent une équipe dédiée à la gestion des systèmes et une autre à la gestion des réseaux. Or, en temps normal, cette frontière est déjà relativement fine ce qui implique nécessairement des recouvrements et potentiellement une zone de flou artistique autour de laquelle le positionnement de chacun peut s’avérer plus complexe.

 J’en prends pour exemple les services d’infrastructures classiques tels que le DHCP, ou le DNS, tantôt gérés par une équipe et tantôt par l’autre. La virtualisation, de par sa structure, a tendance à accentuer cette problématique en incorporant des éléments virtuels, intégrés à une solution déployée et destinée à être gérée du côté systèmes. L’exemple principal qui permet d’illustrer ce propos est la présence dans certaines solutions de « Switchs virtuels », fonctionnant en étroite communication avec la solution de virtualisation mais nécessitant aussi des interconnexions avec le réseau physique de l’entreprise pour bénéficier des accès nécessaires. Par ailleurs, ces switchs ayant un moteur software limité, les fonctionnalités de debug avancé comme le bien nommé SPAN de chez Cisco ne sont pas présentes et ne permettent pas d’analyser rapidement et efficacement les données échangées en cas d’incident. L’administrateur réseau devient donc déjà un peu plus limité sur son panel d’actions possibles.

En outre, la complexité s’accentue avec la combinaison de cette infrastructure virtuelle avec des machines physiques de type « blade », permettant d’obtenir une concentration de serveurs plus importante au sein d’une baie et, par conséquence, limiter le câblage nécessaire au fonctionnement de la toplogie. Le premier point soulevé ici est que cette concentration, bien que bénéfique du point de vue de l’allocation d’espaces au sein du datacenter, peut rapidement devenir problématique car la volumétrie de données échangées au niveau des points d’interconnexion avec le réseau physique. Le dimensionnement initialement prévu devient alors caduque à très court terme s’il ne prenait pas en compte ces paramètres. L’autre point est que ces éléments serveurs, souvent gérées par les équipes systèmes, intègrent pour la plupart des éléments de commutation intégrés propriétaires. Il en découle donc directement l’utilisation d’addins matériels pas forcémment optimisés pour être interconnectés avec les éléments de l’infrastructure réseau existante (propagation de VLANs via VTP pour les infrastructures Cisco et gestion de l’EtherChannel…). Ces équipements, s’ils ne sont pas choisis avec méthode, peuvent donc entraîner une charge d’exploitation supplémentaire car nécessitant des mises à jour bien spécifiques et un temps de formation des équipes pour les appréhender plus ou moins long.

Enfin, bien que les solutions de virtualisation garantissent aujourd’hui une étanchéité complète au niveau des zones de mémoire partagées, l’ajout de cette couche implique indéniablement l’ajout d’un risque de sécurité supplémentaire. La raison toute trouvée pour cela est que les composants de l’infrastructure virtuelle nécessite une gestion des patchs et des évolutions logicielles rigoureuses, car au delà de l’aspect purement relatif au système d’exploitation embarqué, compromettre l’accès à une machine virtuelle tournant sur un serveur d’infrastructure virtuelle présentant des failles de sécurité autoriserait par exemple l’attaquant à rebondir sur d’autres machines plus simplement. C’est par ailleurs pour cette raison que le dessin de l’architecture virtuelle ne doit pas négliger le fait que les périmètres de sécurité réseau doivent être correctement respectés, notamment les fameuses zones de confiance réparties sur les différentes DMZ pour limiter au maximum ce type de menace. L’objectif ici est de ne pas biaiser des éléments avérés depuis plusieurs années, tels que l’étanchéités du protocole 802.1q avec les applicatifs installés dans l’environnement virtuel.

Ces quelques points abordés précédemment militent donc pour le fait que ce type de projet nécessite une étroite collaboration des équipes, pour permettre une évolution en douceur de l’infrastructure réseau et supporter les besoins émis par la virtualisation. Ceci est d’autant plus vrai qu’aborder ces quelques éléments en amont d’un tel projet permettent d’étudier avec précision les étapes nécessaires à la mise en place du socle de base, et, pourquoi pas, de repenser le datacenter dans sa globalité. D’une manière plus générale, c’est ce que font par exemple des solutions comme la gamme Nexus proposée par Cisco, permettant à la fois d’offrir une infrastructure propice au déploiement et à l’accompagnement de la virtualisation tout en apportant son lot d’innovations, basé notamment sur la convergence des réseaux SAN et LAN (vision 3.0 du Data Center par Cisco).
Et vous, quel est votre retour d’expérience sur ce sujet ?