Comment s’adapter aux évolutions récentes de l'architecture réseau des datacenters
Avec l'arrivée du Cloud hybride et des conteneurs, les réseaux des datacenters se sont fortement complexifiés. Mais quelques principes simples demeurent.
Il n'y a pas si longtemps, l'acheminement du trafic dans le datacenter était simple : une adresse IP parlait à une autre. Les adresses appartenaient à des points de terminaison, à savoir des hôtes nus ou des machines virtuelles communiquant avec d'autres. Enfin, le chemin d'une adresse IP à une autre était connu des commutateurs du datacenter grâce à des tables de routage ou de pontage.
Quand un ingénieur s'attaquait à un problème de performance ou à un comportement inhabituel entre deux points de terminaison IP, il commençait par lire ces tables pour établir le chemin entre les deux points. Le partage de charge entre chemins de même coût et l'agrégation de liens multichâssis sont venus complexifier le processus mais dans l'ensemble, les opérateurs pouvaient déterminer précisément le chemin suivi par une conversation donnée dans le datacenter.
Rien ou presque ne venait troubler le flux du trafic entre les points de terminaison. La traduction d'adresses réseau, le chiffrement ou le tunneling étaient rares. Les fonctions de ce type, généralement situées à la périphérie du datacenter, communiquaient avec les appareils extérieurs au périmètre de confiance.
Les temps étaient simples, car les besoins l'étaient.
Le datacenter moderne
Le réseau dans les datacenters modernes est différent car les besoins des entreprises se sont transformés. Le datacenter s'est mué en une plateforme unifiée où s'exécutent des applications. L'infrastructure s'éclipse toujours davantage jusqu'à prendre sa forme la plus moderne : une abstraction sur laquelle les développeurs superposent leurs applications. Les ressources sont allouées à la demande.
Le datacenter moderne gère aussi la sécurité en mode distribué, s'adaptant aux charges de travail qui s'envolent et retombent rapidement. Inutile désormais de faire passer le trafic dans un pare-feu physique centralisé pour appliquer une politique de sécurité. A la place, on établit une politique de sécurité centralisée dont un gestionnaire installe les portions adéquates sur les hôtes, machines virtuelles ou conteneurs affectés. Une telle politique s'applique sans créer de goulet d'étranglement dans l'infrastructure ni faire appel à quelque règle obscure de routage.
Nous venons de décrire globalement une architecture de Cloud privé. L'abstraction de l'infrastructure physique facilite la collaboration avec le Cloud public. Dès lors, les architectures de Cloud hybrides gagnent en popularité.
Les couches
Les architectures hybrides s'imposant comme la nouvelle norme, il convient d'en étudier l'impact sur le réseau. Les mécanismes d'infrastructure qui donnent au datacenter moderne sa flexibilité reposent sur une ingénierie réseau complexe, nécessaire pour séparer les charges, appliquer les politiques aux services et sécuriser le datacenter. Le datacenter moderne ne ressemble plus tant à un océan d'adresses IP qu'à un mille-feuille.
La base du mille-feuille constitue le réseau sous-jacent, sur lequel s'élèveront tous les autres services réseau. C'est aussi le réseau le plus familier aux yeux du technicien réseau type. Lorsqu'ils examinent les tables de pontage et de routage, ils y voient le réseau sous-jacent, autrement dit la pierre angulaire du datacenter.
Mais ce réseau seul ne peut satisfaire tous les besoins d'un Cloud hybride, notamment la ségrégation, appelée multi-tenancy, c'est-à-dire la mutualisation entre plusieurs « tenants » (ou locataires). Un tenant est une application, une unité commerciale ou une entreprise cliente.
Son trafic est séparé du reste du trafic à l'aide de la technologie d'encapsulation VXLAN (Virtual Extensible LAN). Le trafic en provenance d'un segment est encapsulé dans un paquet VXLAN, transporté dans ce contenant et décapsulé à l'arrivée. VXLAN est une seconde couche qui vient se superposer au réseau sous-jacent.
Non seulement VXLAN isole les flux de trafic, mais il sert aussi à le guider sur un chemin donné. Prenons le cas d'un datacenter qui doit envoyer le trafic au travers d'un répartiteur de charge et d'un pare-feu précis. Dans un réseau moderne, ces équipements prennent généralement la forme de fonctions réseau virtualisées susceptibles de résider n'importe où dans le datacenter. Pour acheminer le trafic au bon endroit, l'encapsulation VXLAN va canaliser les flux de trafic en tunnel d'un appareil à l'autre, jusqu'à ce qu'ils soient passés par tous les équipements requis.
Les règles de pare-feu constituent une autre strate du mille-feuille. Un gestionnaire de règles centralisé affecte les règles de pare-feu à chacun des hôtes au cas par cas. Chaque hôte obtient ainsi son propre jeu de règles qui régit son trafic entrant et sortant. Cette micro-segmentation est un moyen pratique d'assurer la sécurité dans un datacenter évolutif.
Une inconnue ajoute encore à la complexité du réseau : le conteneur. La technologie émergente des réseaux de conteneurs, qui s'appuie sur les espaces de noms, les serveurs proxy et la traduction d'adresses réseau pour la communication des conteneurs entre eux et avec le monde extérieur, forme une couche supplémentaire.
Des difficultés en vue pour les opérateurs
Pour les opérateurs, la complexité de l'architecture réseau du datacenter moderne risque de se traduire par certaines difficultés. La plupart des problématiques sont liées à la connectivité ou aux performances ; l'absence de connexion ou la lenteur des communications entre deux points de terminaison en sont des exemples.
Imaginons la résolution d'un problème de connectivité selon la méthode packet walk. Il nous faut suivre le chemin que prend un paquet pour arriver à sa destination, ce qui ne pose aucun problème si on connaît les points de terminaison IP.
Dans le datacenter moderne, le réseau sous-jacent sert à transmettre les paquets VXLAN ou d'autres couches supérieures. Si on ajoute des règles de pare-feu, voire des services de traduction d'adresses réseau ou de proxy, la procédure se complique et s'alourdit. Pour diagnostiquer un souci de connectivité, un opérateur doit connaître la source et la destination du paquet : le conteneur, la machine virtuelle ou l'hôte nu, les politiques de pare-feu qui régissent le paquet, l'encapsulation du paquet et la chaîne de services à suivre.
En supposant que l'opérateur comprend le flux d'application et fonctionne selon une organisation IT décloisonnée et à plat, le problème est épineux mais pas insurmontable. Repérer les contrôles d'accès aux appareils et leurs adresses IP dans les tables de routage et de pontage ne représente qu'une infime partie d'une procédure de dépannage plus élaborée. Ajoutons à cela la nature souvent éphémère de l'infrastructure : les opérateurs pourraient être amenés à dépanner des problèmes passés impossibles à reconstituer.
Les problèmes de performance sont encore plus difficiles à diagnostiquer. A lui seul, le nombre d'équipements réseau impliqués dans une conversation donnée comprend généralement un système d'exploitation virtuel, un commutateur virtuel sur un hyperviseur, un pare-feu virtuel, un commutateur en haut de rack (ToR), un commutateur « spine », et la même énumération en sens inverse jusqu'à l'autre point de terminaison.
Si certaines charges se trouvent dans le Cloud public, les choses se compliquent encore. Avec l'infrastructure ou la plateforme à la demande, viennent s'ajouter la latence élevée et un surcroît de tunneling.
Les réponses du secteur
IP est encore là pour un moment. Il faut faire avec et lui ajouter des fonctionnalités : les réseaux superposés qui nous permettent de guider et d'isoler le trafic ne sont pas près de disparaître non plus. Grâce à cette fonctionnalité, nous pouvons traiter l'infrastructure comme des pools de ressources, en y ajoutant ou retirant de la capacité à volonté. Il s'agit dès lors de gérer la complexité réseau que nous avons ajoutée à nos environnements.
Le secteur des réseaux s'est attaqué à ce défi selon deux angles. D'abord par l'acceptation : nous acceptons le fait que la complexité ne va pas disparaître et fournissons par conséquent les outils qui permettent de mettre au jour ou de visualiser ce qui se passe sur le réseau.
C'est l'exemple de Cisco, qui propose aux opérateurs des outils sophistiqués de dépannage de la connectivité de bout en bout pour sa plateforme d'infrastructure axée sur les applications. VMware a récemment acquis Arkin : cet outil de visualisation met en corrélation les workloads avec la politique de pare-feu et la segmentation VXLAN dans une interface graphique combinée à un moteur de recherche en langage naturel.
L'existence d'outils de dépannage et de visualisation efficaces dans les plateformes de datacenter modernes est vue de plus en plus comme un point fort. Toutefois, certains ont réagi à la complexité en créant des schémas de transmission de paquets qui évitent autant que possible les superpositions.
Par exemple, le projet open source Romana.io s'appuie sur un schéma hiérarchique d'adressage IP qui, combiné à des règles de pare-feu dépendant des hôtes, crée la segmentation et une politique de sécurité centralisée. Le projet open source Project Calico lui est comparable. Tous deux sont intéressants en ce qu'ils proposent des schémas d'acheminement qui s'adaptent aux gros datacenters mais continuent de prendre en charge les besoins en termes de sécurité et de segmentation, sans superposition.
Et si la plus grande interrogation concernait moins la gestion de la complexité du réseau que les personnes qui en assurent la maintenance ? On raconte que l'automatisation amènera une réduction des effectifs des personnels IT.
Fort de mes 20 ans d'expérience des infrastructures IT, je suis d'un tout autre avis. La complexité accrue crée la demande d'une assistance supérieure. Quand la magie disparaît, les entreprises ne veulent pas faire le pied de grue devant leurs fournisseurs. Elles veulent s'appuyer sur des professionnels, fins connaisseurs de leur système et prêts à réparer ce qui ne fonctionne pas.
