Résumé

  • Dans Firehose 1.0, deux pannes particulières de liaisons montantes pouvaient empêcher deux groupes de machines de communiquer entre eux sans les couper du reste du réseau. Ce premier système n'a jamais acheminé de trafic de production.
  • La maintenance par blocs indépendants a ensuite borné certaines interventions, sans supprimer les risques communs liés au contrôle, aux configurations et aux procédures.
  • Le rôle documenté de Urs Hölzle et sa participation à une publication collective permettent d'étudier cette évolution ; ils ne lui attribuent pas chaque décision de conception.

Une machine communique avec d'autres. Une seconde en fait autant. Pourtant, elles ne peuvent pas se parler. Dans un réseau destiné à relier largement les serveurs d'un centre de données, cette situation est plus gênante qu'une coupure franche : l'application ne trouve pas une frontière simple entre ce qui fonctionne et ce qui ne fonctionne plus.

Les auteurs de Jupiter Rising, publié à SIGCOMM en 2015, décrivent précisément cette difficulté dans Firehose 1.0. La défaillance de deux liaisons montantes opposées sur deux commutateurs de haut de baie, au cours d'une même période de réparation, pouvait créer cette connectivité non transitive. Le système n'a jamais transporté de trafic de production. Il faut donc lire le passage comme un retour sur une tentative de conception, non comme l'annonce d'un incident actuel.

Une responsabilité qui dépassait les commutateurs

Urs Hölzle figure parmi les nombreux coauteurs de cette rétrospective. Sa biographie chez Google Research le présente comme Google Fellow au sein de Google Cloud et précise qu'il a été Senior Vice President for Technical Infrastructure jusqu'en 2023. Il supervisait alors la conception, l'installation et l'exploitation des serveurs, réseaux et centres de données utilisés par les services de Google.

Ce périmètre explique l'intérêt du personnage pour une histoire de maintenance. La topologie n'était pas un objet isolé : il fallait la construire, y placer des charges de travail et la faire évoluer. En revanche, ni le titre de Hölzle ni sa signature ne permettent de désigner l'auteur individuel de chaque solution. Le document rend visible un apprentissage d'équipe, avec des difficultés matérielles et opérationnelles que le récit du seul inventeur ferait disparaître.

Une annonce de mai 2013 et son texte de mars 2020 sur le réseau attestent ce rôle à deux moments datés. Le second distingue aussi le réseau de Google du dernier kilomètre assuré par les fournisseurs d'accès. Cette responsabilité ne doit être étendue ni à toutes les dépendances d'un utilisateur, ni à une garantie générale de disponibilité aujourd'hui.

Quand la résilience réclame du trafic

La rétrospective relie un choix de fiabilité des applications à un besoin de bande passante. Répartir calculs et stockage entre plusieurs domaines d'alimentation et de panne limite l'exposition à un problème local. Mais cette dispersion affaiblit la proximité physique qui aurait gardé les échanges dans un même petit groupe de machines.

Un réseau Clos à plusieurs étages multiplie les chemins en assemblant de nombreux éléments de commutation. Il permet de penser un grand ensemble autrement que comme un unique châssis géant. Le défaut de Firehose 1.0 rappelle toutefois que les chemins doivent rester utiles aux bonnes paires de machines dans les combinaisons de panne considérées. Une redondance visible ne suffit pas à décrire la continuité d'une application.

Firehose 1.1 a modifié l'assemblage physique et la structure des connexions. Des boîtiers dédiés ont remplacé les serveurs ordinaires qui hébergeaient les puces de commutation ; le système comportait un réseau de contrôle distinct, des commutateurs de baie appariés et une agrégation revue. Les auteurs rapportent une meilleure robustesse face aux défaillances de liens. Ils décrivent aussi le coût en travail du câblage et les contraintes de placement. La réparabilité se joue jusque dans la manière dont on installe et reconnecte les éléments.

Retirer un bloc : quelle perte réelle ?

Avec Freedom, l'unité d'intervention devient explicite. Une couche de connectivité typique comprend quatre blocs indépendants. On peut détourner le trafic d'un bloc, le retirer du service et le mettre à niveau, avec une réduction de 25 % de la capacité agrégée. C'est une propriété de l'agencement décrit, pas la promesse que toutes les charges conservent leur performance pendant l'opération.

Le même article fournit un contrepoint utile. Dans une autre illustration, les châssis d'un réseau Clos sont répartis en quatre ensembles pour une mise à niveau progressive. En désactiver un ne laisse que 56,25 % de capacité : les pertes se combinent entre étages. Une procédure en huit ensembles est moins brutale mais plus longue. Il ne faut pas confondre cette illustration avec les blocs indépendants de Freedom.

Le nombre d'équipements retirés est donc une mauvaise mesure, à lui seul, de l'effet d'une intervention. La bonne question porte sur les chemins qui subsistent, leur charge et le travail qui peut encore s'y répartir.

Ce qui reste commun

Pour Firehose, Watchtower et Saturn, Firepath diffuse un état commun de topologie et de liens, tandis que chaque commutateur calcule localement ses tables de transfert. La coordination est logiquement centralisée ; elle n'équivaut pas à une décision centrale pour chaque paquet. Des instances de contrôle redondantes et un réseau séparé soutiennent ce fonctionnement. Les détails du contrôle de Jupiter sont, eux, explicitement hors du périmètre de l'article.

Avant Jupiter, une petite série de paramètres de cluster produisait aussi les listes de matériel, plans de baies et de câbles, données de supervision et configurations communes. Réduire les choix favorisait la construction répétable. Cela donnait en retour une grande portée à la justesse de la spécification partagée.

Les cas d'exploitation rapportés rendent ce risque concret. Un redémarrage simultané du réseau a fait entrer les contrôles de présence et le calcul des routes en concurrence pour les ressources limitées des processeurs de commutation. Le vieillissement de liens internes et du réseau de contrôle a exposé des cas mal couverts par la surveillance. Lors d'une modification BGP sur Freedom, une lecture de configuration non verrouillée a interagi avec une écriture et abouti à une configuration partielle. Les auteurs indiquent avoir rétabli l'état précédent et renforcé les outils.

Ces passages ne donnent ni une fréquence générale de panne, ni des durées, ni un bilan des dommages aux clients. Ils montrent plutôt pourquoi la séparation matérielle ne constitue pas, à elle seule, une séparation opérationnelle.

Un résultat collectif, une question durable

La publication de 2015 et l'édition CACM de 2016 sont deux versions du même travail. Elles ne forment pas deux validations indépendantes. Ce témoignage de l'exploitant éclaire les mécanismes historiques sans établir la configuration actuelle de ses centres de données.

Dans cette histoire, l'importance de Hölzle tient au lien documenté entre une responsabilité d'infrastructure et un travail collectif qui a rendu le réseau transformable par parties. La question durable est très pratique : lorsqu'un morceau quitte le service, qu'est-ce qui demeure réellement indépendant, et qu'est-ce qui continue à partager le même changement ou la même défaillance ?

Sources