ACTUALITÉ SCIENTIFIQUE
ET INNOVATION DE L'ÉTS
Améliorer la disponibilité dans une immense infrastructure réseau : l’expérience de Google - Par : Aifa Sassi, Tara Nath Subedi,

Améliorer la disponibilité dans une immense infrastructure réseau : l’expérience de Google


Bikash Koley est directeur de l'architecture réseau, ingénierie et planification chez GoogleLes professeurs Mohamed Cheriet et Kim Khoa Nguyen du laboratoire de recherche Synchromedia ont organisé une mini-conférence, dans le cadre de la 12e conférence internationale sur la gestion des réseaux et services (CNSM) de l’IEEE, qui s’est tenue du 31 octobre au 4 novembre 2016 à l’École de technologie supérieure (ÉTS).

Cet article est un aperçu de l’axe de recherche portant sur Zero Touch Network (ZTN), présenté par Bikash Koley, Ingénieur brillant et directeur de l’architecture réseau, ingénierie et planification chez Google. Il a été écrit par des étudiants-chercheurs du laboratoire de recherche Synchromedia, qui ont assisté à cette conférence.

 

L’immense infrastructure réseau

Le réseau construit par Google est basé sur une immense infrastructure comprenant deux dorsales internet : B4 et B2. B4 est le WAN (Wide Area Network) privé qui sert à interconnecter les grappes (clusters) de serveurs de Google dans le monde entier et B2 est la deuxième dorsale qui sert à interconnecter les centres de données Google à l’internet. B4 est une dorsale SDN (Software-Defined Networking) internationale à gestion centralisée et B2 est la plus grande dorsale de réseau IP (Internet Protocol) au monde. Cette infrastructure héberge les applications en temps réel en respectant les conditions essentielles relatives à la bande passante et aux retards de transmission. La vidéo suivante présente l’infrastructure d’une seule grappe (cluster) Google; alors, imaginez l’énorme infrastructure qui sert à interconnecter les centres de données Google à l’échelle planétaire (B4 et B2)!

L’objectif principal des fournisseurs d’infrastructure infonuagique comme Google est d’offrir le plus haut niveau de disponibilité afin de maximiser l’utilisation des ressources et de minimiser le coût total d’entretien et de configuration. Mais étant donné l’évolution exponentielle des besoins en bande passante et en qualité de service, ou QoS, des applications et l’expansion de l’infrastructure, il est difficile d’assurer et de garantir le niveau de disponibilité nécessaire tout en maintenant l’évolutivité, l’efficacité et la fiabilité du réseau. Dans ce contexte, nous partageons ici l’expérience de Google.

Pourquoi la disponibilité élevée du réseau est-elle un défi?

Dans cette immense infrastructure, même lorsque la probabilité de défaillances est égale à 0,1 %, le nombre de défaillances par jour est énorme; en fait, ce nombre augmente avec la taille du réseau. C’est pourquoi il est très important de modéliser le nombre de défaillances pouvant survenir à mesure que le réseau évolue et de construire un modèle efficace et suffisant pour assurer la redondance. En fait, augmenter la redondance de façon massive pour éviter les défaillances n’est pas la solution parce que c’est un gaspillage de ressources et d’efforts. Donc, l’objectif principal de Google est de construire un système à même le budget de défaillances; il ne s’agit pas de minimiser seulement le nombre de défaillances, mais d’équilibrer leur fréquence avec le budget de pannes existant, tout en tenant compte de ces facteurs : la vitesse d’évolution, le besoin d’évolutivité et la complexité de la gestion. Ainsi, pour atteindre son objectif principal, Google propose de se concentrer sur la durée moyenne de réparation (MTTR, Mean Time to Repair) au lieu de maximiser le temps moyen de bon fonctionnement (MTBF, Mean Time between Failures).

Entre les opérations réseau et l’analyse des défaillances

Une infrastructure évolutive, fiable et efficace

« Google veut assurer l’évolutivité, la fiabilité et l’efficacité de son infrastructure et les approches classiques sont incapables de garantir ces trois spécifications en même temps. »

Bikash KOLEY

 

 

Pour assurer l’évolutivité, la fiabilité et l’efficacité, Google propose d’analyser les défaillances afin de comprendre leur nature et leurs causes. Pour atteindre cet objectif, Google a recours à une approche post-mortem basée sur une analyse approfondie des défaillances. Cette technique, à la différence d’un registre d’incidents ou d’un journal d’événements, est une description structurée des défaillances. Ce processus est dit « sans blâme », afin d’assurer que tous contribuent à la description de la défaillance. Un post-mortem est seulement produit pour les défaillances inédites qui ont causé des problèmes importants. Il contient les détails suivants sur chaque défaillance : durée, description de l’effet sur les utilisateurs (suivie d’une chronologie détaillée des événements précédant la panne), ce qui s’est passé pendant la panne, ce qui s’est produit après réparation de la défaillance et, enfin, les causes à la base de la défaillance obtenues après l’analyse des événements, la révision du code et la reconstitution de la défaillance en laboratoire. Le processus se poursuit avec une discussion sur ce qui a fonctionné et ce qui n’a pas fonctionné, tout en essayant de résoudre le problème causant la défaillance. Ensuite, les mesures qui suivent les différentes décisions visant à régler la défaillance peuvent mener à des changements de code ou de processus.

Une analyse de 100 rapports post-mortem rédigés sur une période de deux ans a donné lieu à trois observations précises :

  • Contrairement aux présomptions de l’équipe, il existe une grande similitude des types d’échecs dans les dorsales Google B4 et B2, et aucun réseau (B2, B4, cluster) ne domine en ce qui a trait aux cas de défaillances.

Donc la leçon principale à tirer ici est la suivante : « Il ne faut pas se concentrer sur un seul réseau ou un seul niveau si on veut renforcer le réseau. »

  • 80 % des défaillances se situent entre 10 et 100 minutes, dépassant largement le budget de pannes (4 minutes par mois, pour une disponibilité de 99,99 %).
  • 70 % des défaillances surviennent lorsqu’une opération de gestion est en cours.

Solution proposée : Zero Touch Network

Le fonctionnement du réseau doit être entièrement axé sur l'intention« {la fiabilité, l’efficacité et l’évolutivité} peuvent être toutes les trois atteintes… si le fonctionnement du réseau est entièrement axé sur l’intention» 

Bikash KOLEY

 

 

L’architecture ZTN (Zero Touch Network) présente les caractéristiques suivantes :

  • Automatisation : toutes les opérations du réseau sont automatisées, ne nécessitant aucune intervention de l’opérateur au-delà de l‘instanciation de l’intention. Les êtres humains peuvent avoir des hauts et des bas et commettre des erreurs; par conséquent, il est très important de minimiser les opérations manuelles dans l’approche ZTN.
  • Autoconfiguration : les modifications apportées aux différents éléments du réseau sont entièrement déclaratives, non propriétaires et dérivées de l’infrastructure réseau à partir de l’intention de haut niveau à l’échelle du réseau. En fait, la vérité sur la configuration et la structure du réseau doit provenir du modèle et du logiciel centralisé conçu pour gérer et surveiller le réseau. Dans ce cas, si on n’apporte pas de modifications aux sous-systèmes ou aux éléments, on n’a pas à faire d’études complexes sur l’incidence des changements.
  • Sécurité : toute modification de réseau est automatiquement arrêtée et renversée si le réseau affiche un comportement non souhaité et l’infrastructure ne permet pas les opérations qui contreviennent aux politiques de réseau.

Architecture Zero touch networkDans l’architecture ZTN, les opérateurs ne doivent jamais interagir directement avec des éléments réseau, mais l’agent de gestion de processus, un système logiciel, peut interagir avec l’infrastructure décrite par le modèle de configuration et signaler l’état du réseau présenté par le modèle de topologie au moyen des API transactionnelles.

La dernière partie de cette architecture est la couche de gestion de réseau dont les missions sont de : détecter les changements dans le modèle de configuration, construire un nouveau modèle de configuration complète pour les éléments de réseau en fonction de ces changements et l’intégrer au modèle de réseau.

Connaître instantanément l’état du réseau est une partie essentielle de l’architecture proposée; ici, la télémétrie streaming sert à évaluer le comportement du réseau après avoir intégré le changement de configuration dans le modèle de réseau. La télémétrie streaming est utilisée comme outil servant à la vérification de la sécurité des opérations et pour évit