Pour Amin Vahdat de Google, « Espresso est le 4ème pilier et sans doute le plus ambitieux de la stratégie SDN de Google. Il élargit notre approche complète vers un « peering » à la périphérie de notre réseau avec les autres réseaux de la planète »
La conférence Open Networking Summit (ONS) s’est tenue au début de mois d’avril à Santa Clara, organisée par la Foundation Linux. Incontournable lieu de rencontres de l’Open Source pour les développeurs, les équipementiers et les opérateurs de réseaux de données depuis 2011. Elle permet de découvrir les derniers développements dans le secteur des réseaux de données. A cette occasion, Amin Vahdat, Google Fellow et Technical Lead for Networking présentait Espresso, une nouvelle pièce de son architecture de réseau, développé par Google et mis en œuvre en interne depuis 2 ans sur la périphérie de son réseau.
Computing is the network
L’approche réseau de Google et le déploiement de sa stratégie SDN (Software Defined Network) date de plus de 10 ans et s’appuie sur une démarche interne propriétaire qui consiste à développer ses propres matériels et logiciels pour répondre à un cahier des charges précis et exigeant puis, après une période de mise en œuvre et de test en interne, de rendre accessible ces innovations en mettant certains éléments en Open Souce. « Le réseau de Google est bien plus qu’un ensemble de data centers, expliquait Amin Vahdat. Avec plus de 200000 serveurs, il est probablement le plus grand réseau privé du monde et il génère plus de 25% du trafic internet dans le monde à partir de nos services (mail, search, advertising, mapping, etc.). Il s’appuie sur une centaine de points d’accès répartis sur toute la planète, qui nous ont permis de passer des partenariats avec les ISP locaux dans 70 métropoles. »
Epine dorsale des services proposés par Google, l’architecture de ce réseau doit répondre à des besoins de scalabilité, de réaction en temps réel quel que soit l’endroit, de flexibilité, de disponibilité et de bande passante, ce qui a conduit Google à le développer, par ses propres moyens matériels et logiciels, selon quelques principes qui aujourd’hui sont communément regroupés sous le terme de SDN. Pour Google, la stratégie SDN est le moyen de faire disparaitre le réseau, c’est le réseau qui est le lieu de traitement « Computing is the network. » Le réseau en quelques sortes, remplace le PC et offre du traitement à la demande.
Faire disparaitre le réseau
La stratégie SDN de Google est basée sur la désagrégation entre le stockage et les unités de traitement, ce qui implique que « nous ne recherchons pas le serveur qui traite une certaine catégorie de données, mais nous répliquons les données à travers tous nos data centers. Nous voulons accéder à n’importe quoi n’importe où avec un temps de latence extrêmement réduite. Cela implique que nos data centers doivent être capable de s’interconnecter à des niveaux de bande passante de l’ordre de 1 petabits par seconde, pour tous nos services. »
Bande passante très élevée, faible latence,
haute disponibilité et moindre coût de fonctionnement…
Une autre caractéristique de l’approche SDN, qui, selon Amri Vahdat a toujours été au cœur du fonctionnement de Google, est de séparer la logique et le contrôle de la gestion du trafic qui jusqu’à présent étaient intégrés au sein des routeurs, en général optimisé pour la connectivité et qui apprennent à partir des flux de paquets qui circulent entre eux. Google, s’appuyant sur son infrastructure de traitement à large échelle a mis en place un système de contrôle centralisé et s’appuie sur les applications elles-mêmes pour adapter et optimiser les performances des flux demandés à la périphérie par les utilisateurs en fonctions de leurs besoins. Ainsi, Google sépare le monitoring, le management et les opérations des « boites » qui sont décentralisées. A ce titre, Google utilise Open Flow, le protocole de base des SDN, dans les switches et les routeurs qu’il construit, mais il ne précise pas si ses matériels sont compatibles avec les autres routeurs open flow du marché.
La désagrégation est au cœur des SDN…
Les 3 piliers du réseau Google
La mise en place du réseau de Google s’est déroulée en plusieurs étapes dont les premiers éléments remontent à la création du système de gestion de fichier Google (GFS) en 2002, devenu aujourd’hui Spanner, un véritable système de gestion de données distribuées (NewSQL).
Mais le premier pilier du réseau de Google se situe dans le réseau privé d’interconnexion de ses data centers, appelé B4. Google l’a mis en place et fait évoluer en fonction des services et applications qu’il développait, en le basant sur ses propres hardwares qui ont commencé à utiliser OpenFlow dès 2011. B4 a un certain nombre de caractéristiques importantes dont la bande passante capable de répondre a la demande de tous les sites, un système d’optimisation et d’équilibre de la bande passante en fonction des flux et un total contrôle des serveurs dans le réseau et à la périphérie.
Le deuxième pilier qui fut annoncé en 2012 est l’architecture des data centers, appelée Jupiter. D’une capacité 100 fois supérieure au premier data center de 2005 appelé Firehose, c’est un réseau organisé autour d’une topologie dite Clos, basée sur un modèle idéal de réseau de commutation. Un rassemblement de petits switches pas chers est organisé et géré pour fournir les fonctionnalités d’un switch unique plus gros, offrant ainsi la scalabilité. Ces switches pas chers, construits par Google, sont contrôlés par un système distribué développé par Google, centralisé au niveau du data center.
L’architecture de Jupiter
Le troisième pilier annoncé en 2014 s’appelle Andromeda, c’est une architecture qui permet la virtualisation selon l’approche SDN (NFV). Différente d’une pure plateforme de Cloud, elle permet cependant de fournir aux utilisateurs du Cloud Google une expérience à la demande simple et immédiate, sure, disponible, performante. Elle est dotée des éléments qui permettent d’orchestrer les machines virtuelles de chaque utilisateur, de les superviser et de leur offrir les services demandés en applications, stockage, bande passante et sécurité… Google offre les mêmes capacités de traitement sur le réseau à ses clients que ce qu’il offre à ses services en interne, tout en les gardant complètement isolés, indépendants et scalables. Andromeda permet à Google de tester et de délivrer rapidement de nouvelles fonctionnalités de services
Espresso, le 4ème pilier pour s’ouvrir plus largement à l’internet public
Ce quatrième pilier a pour objectif de rendre le Cloud plus rapide, plus flexible et moins cher en étendant le SDN vers l’Internet publique. Amin Vahdat poursuit en évoquant le problème suivant : « Considérons une recherche vocale en temps réel avec Google Assistant qui demande les dernières nouvelles…Cette requête, formulée à la périphérie du système à l’un des data centers, est enregistrée. Il faut alors consulter des milliers de serveurs qui doivent parcourir une vaste quantité de données qui ressemblent à la phrase de la question posée, qu’il aura fallu traduire dans différents langages et/ou dialectes. Une fois trouvée, la phrase résultante est transmise à un autre cluster qui effectue une recherche Web et consulte un index en temps réel de contenus internet. Le résultat est évalué et ensuite retourné à la périphérie du réseau à l‘utilisateur qui a posé la question. Répondre à la question en temps réel demande la coordination de dizaines de routeurs Internet et de milliers d’ordinateurs à travers le monde, tout ceci en moins d’une seconde…Le réseau doit aussi répondre à des centaines de milliers de demande de ce genre à travers le monde, durant cette même seconde… «
Espresso innove de deux manières : Plutôt que de connecter un utilisateur à un point statique basé sur leur adresse IP (or l’adresse IP de leur DNS), Espresso permet à Google de choisir dynamiquement d’où il va servir cet utilisateur. Ceci permet à Google d’équilibrer le trafic basé sur les performances réelles des données en cours et des applications, et de réagir en temps réel à d’éventuelles congestions ou des chutes du réseau. Il offre une couche de contrôle supplémentaire sur une sorte d’overlay périphérique qui ne nécessite pas d’entrer dans le cœur du réseau et qui permet à Google de discuter plus facilement avec les entités extérieures puis de livrer les ressources à la demande avec plus de flexibilité et de performance, à moindre coût. Il leur offre ainsi les mêmes performances que les applications natives de Google comme Gmail, Youtube ou Search…
puis