Les centres de données sont construits autour de ressources de calcul et de stockage consommables depuis des décennies. Cependant, le réseau et les commutateurs nécessaires pour prendre en charge cela n’étaient pas inclus. Pour cette raison, les hyperscalers ont rencontré des limites d’évolutivité et, depuis un certain temps, ont construit des réseaux qui tentaient de répondre aux demandes de calcul et de stockage. Les fournisseurs d’équipements de réseau ont mis du temps à emboîter le pas ; peut-être parce que leurs entreprises ont été construites autour de la vente de matériel spécialement conçu.
A propos de l’auteur
Erwan James est architecte de solutions principal et responsable régional de la ligne de produits pour l’activité Global Webscale de Nokia.
Le moment est venu pour les fournisseurs de réseaux de changer leur façon de penser. Alors que l’interconnexion des centres de données et les clouds périphériques distribués deviennent la norme, en particulier pour les entreprises de service qui adoptent l’Industrie 4.0, il est temps que les commutateurs deviennent plus consommables. En d’autres termes : avoir la capacité de s’adapter aux besoins en constante évolution de l’environnement informatique.
Sommaire
Demandes émergentes
COVID-19 a illustré que, même avec une consommation de services informatiques de base, les modèles de trafic réseau peuvent changer considérablement en raison de transitions soudaines à grande échelle ; dans ce cas, vers le travail à distance et une explosion de services vidéo et de jeux dirigés par les consommateurs.
Cependant, les modèles de demande de réseau pour les services de cloud computing de périphérie seront beaucoup plus variables avec l’industrie 4.0. Et, avec le passage aux services sans fil 5G d’entreprise, le réseau devra adopter des principes natifs du cloud pour fournir l’évolutivité élastique nécessaire pour répondre à ces demandes émergentes des entreprises. Les fournisseurs de cloud, de colocation et d’interconnexion ne pourront conquérir ce marché avec succès que s’ils peuvent, comme les hyperscalers d’aujourd’hui, faire évoluer le réseau de la même manière qu’ils gèrent actuellement les ressources de calcul et de stockage.
Idéalement, le réseau suivra bon nombre des mêmes pratiques établies par les centres de données pour les autres consommables. Les fonctions et applications réseau doivent être fournies à l’aide de microservices distribués sur des plateformes telles que Kubernetes qui sont basées sur l’intention, tout en automatisant une grande partie du cycle de vie de ces microservices. Les fonctions et les applications doivent être observables, ce qui signifie que la télémétrie doit être plus granulaire et sophistiquée lors de la capture des performances du réseau. Et, enfin, la structure du réseau doit pouvoir échouer en douceur avec un impact limité sur le service et récupérer automatiquement.
Tissu de réseau
Les infrastructures informatiques des centres de données à grande échelle disposent généralement d’un grand nombre de serveurs hébergeant des applications cloud distribuées. Pour fournir un réseau consommable doté à la fois d’une connectivité évolutive et d’une gestion opérationnelle du cycle de vie automatisée, les groupes de commutateurs du réseau du centre de données doivent être gérés en tant qu’unité logique, appelée matrice, avec une automatisation pour toutes les phases du cycle de vie opérationnel de la matrice : y compris la conception Day-0, le déploiement Day-1 et les opérations Day-2+.
Pour fournir une automatisation à grande échelle, les opérations Fabric doivent avoir accès à des intentions de conception abstraite basées sur des modèles. En option, les fournisseurs de réseaux peuvent également pré-certifier ces modèles dans leurs propres laboratoires. Avec ces modèles, la création du réseau peut être automatisée selon des conceptions vérifiées et validées. Dans ce modèle, les modèles de conception de tissu automatiseraient une grande partie des tâches de configuration répétitives et banales, en suivant les entrées ou les intentions de conception de niveau supérieur. L’intention abstraite doit se concentrer sur les constructions génériques de l’infrastructure du centre de données, telles que le « nombre de racks », « serveurs par rack », « double hébergement », etc.
Pour assurer une connectivité transparente pour les charges de travail d’application basées sur le service de réseau virtuel (VNS) ou le service de réseau convergé (CNS) sur un réseau CLOS multicouche, une connectivité de couche 2 ou de couche 3 basée sur des normes est requise. Tout doit être « ouvert sur le fil », en exploitant des protocoles standard, tels que EVPN-VxLAN ; qui devient un élément constitutif de la mise en réseau des services.
Comme pour DevOps, il doit également exister une méthodologie NetOps qui garantit que l’automatisation basée sur l’intention peut être exprimée sous une forme déclarative ou sous forme d’« infrastructure en tant que code ». Ceci est important pour les solutions couvrant les clouds hybrides sur site et hors site. Il devrait également être possible d’apporter des modifications fréquentes à la configuration du réseau, tout en gérant le risque d’un changement au sein d’un jumeau numérique du réseau réel – un bac à sable numérique réseau. Cela devrait permettre à NetOps d’expérimenter, de tester et de valider diverses étapes d’automatisation et, plus important encore, de valider les scénarios de défaillance et l’automatisation en boucle fermée associée sans risquer de les essayer sur le réseau de production. Un bac à sable numérique peut également être utilisé pour tester et valider de nouvelles applications réseau, activer de nouveaux protocoles ou lors de la migration vers une nouvelle topologie de réseau.
L’automatisation implique l’observabilité, mais cela doit aller au-delà des journaux de télémétrie habituels qui capturent des données de performances réseau non interprétées. À mesure que les fabrics distribués évoluent, la complexité nécessite plus que la logique métier habituelle pour comprendre ce qui se passe. Une base de référence et des analyses avancées de l’apprentissage automatique doivent être utilisées pour fournir des observations faciles à comprendre. L’extraction et la fourniture d’informations contextuelles permettront à l’opérateur de comprendre la cause première d’un problème et d’effectuer des actions correctives ainsi qu’une automatisation en boucle fermée de manière programmable.
Intégrations
Enfin, avec une architecture de système vraiment ouverte, l’automatisation du réseau devrait pouvoir s’intégrer dans un écosystème environnant en permettant des « intégrations » enfichables avec des piles SDDC (Software-Defined Data Center), telles que les piles VMware ou Kubernetes. Ici, le réseau doit s’aligner si étroitement sur l’écosystème qu’il suit les besoins des applications et devient invisible jusqu’à ce qu’un problème survienne.
Le mantra de la structure de réseau consommable doit être le même que les opérations du centre de données en général : être simple, plus agile, fusionner les modifications fréquemment, piloter les modifications à l’aide de l’automatisation et valider l’état final à l’aide de la pile de gestion. Déployez des workflows ou des applications directement sur le réseau, consommez des cycles CPU auparavant inactifs, obtenez des informations pertinentes localement et effectuez des actions immédiatement, le tout pris en charge par un environnement de développement robuste pour les applications réseau prenant en charge un large éventail de langages de programmation. C’est la clé pour s’assurer que le réseau fait partie intégrante de la plate-forme d’innovation du centre de données, en tant que catalyseur, et non inhibiteur, pour répondre aux demandes des clients.
