Resumen

  • Un fallo concreto de dos enlaces ascendentes en Firehose 1.0 podía dejar a dos grupos de máquinas conectados con otros, pero incomunicados entre sí. Ese diseño nunca llevó tráfico de producción.
  • Los bloques independientes redujeron después el alcance de algunas tareas de mantenimiento. La separación física no eliminó las dependencias comunes de software y configuración.
  • La responsabilidad documentada de Urs Hölzle y su firma en un trabajo colectivo sitúan al personaje en esta historia, sin atribuirle todas las decisiones técnicas.

Antes de preguntar cuánto transporta una red, conviene preguntar qué se pierde al intervenir en ella. Ni siquiera la respuesta «esas máquinas siguen conectadas» basta siempre. En un diseño temprano de Google, dos grupos podían comunicarse con otras máquinas y, aun así, no hacerlo entre ellos.

El artículo original presentado en SIGCOMM en 2015 explica la condición. En Firehose 1.0, el fallo de enlaces ascendentes situados en lados opuestos de dos conmutadores de cabecera de rack, dentro de una misma ventana de reparación, podía producir esa conectividad no transitiva. Para las aplicaciones era una situación difícil de manejar: no había una isla aislada con un límite sencillo.

El episodio no debe convertirse en una noticia sobre una caída actual. Los autores afirman que Firehose 1.0 nunca transportó tráfico de producción. Es una lección de diseño e implantación que ayuda a entender por qué las versiones siguientes cambiaron algo más que la velocidad de los enlaces.

El vínculo con Hölzle

Urs Hölzle aparece entre los numerosos coautores de la retrospectiva. Su biografía en Google Research lo identifica como Google Fellow en Google Cloud y señala que fue Senior Vice President for Technical Infrastructure hasta 2023. En ese cargo supervisaba el diseño, la instalación y la operación de servidores, redes y centros de datos para los servicios de Google.

Ese ámbito reúne decisiones que suelen contarse por separado: construir la red, distribuir trabajo entre máquinas y mantener el conjunto en funcionamiento. Por eso su trayectoria resulta pertinente. Pero la biografía y la coautoría no revelan quién ideó cada mecanismo ni permiten asignarle las intenciones de todo el equipo.

Una publicación de Google de mayo de 2013 y el texto de Hölzle de marzo de 2020 acreditan aquella responsabilidad en momentos concretos. El segundo distingue, además, la red de Google del último tramo que prestan los proveedores de acceso. No todas las dependencias de una conexión de usuario estaban bajo el mismo control.

La fiabilidad cambia dónde circulan los datos

El trabajo técnico describe una relación importante entre aplicaciones e infraestructura. Distribuir tareas y almacenamiento entre dominios de alimentación y fallo reduce la exposición a un problema local. También separa físicamente recursos que necesitan comunicarse. La decisión de diversificar el riesgo exige entonces más intercambio entre grupos de máquinas.

La topología Clos responde mediante varios niveles de conmutación y muchos caminos. Permite construir una red grande con numerosos elementos en lugar de depender exclusivamente de un enorme chasis. Sin embargo, el ejemplo de Firehose 1.0 muestra que contar caminos no garantiza que sobreviva la relación precisa que una aplicación necesita ante una combinación concreta de fallos.

Firehose 1.1 modificó tanto el montaje como las conexiones. Sustituyó los servidores ordinarios que alojaban chips de conmutación por recintos dedicados e incorporó una red de control separada, conmutadores de rack emparejados y una agregación revisada. Los autores describen una mayor robustez frente a fallos de enlaces. El cableado seguía exigiendo trabajo y una colocación cuidadosa. La arquitectura debía tolerar la realidad de instalar, reconectar y sustituir piezas.

No toda cuarta parte significa lo mismo

En la arquitectura posterior Freedom, una capa típica de conectividad estaba formada por cuatro bloques independientes. Era posible retirar el tráfico de un bloque y actualizarlo, reduciendo la capacidad agregada un 25 %. El conjunto no tenía que tratarse como una sola unidad de mantenimiento.

La cifra corresponde a esa disposición. No prueba que cada aplicación conserve su rendimiento durante la retirada: la carga tiene que caber en los recursos disponibles y puede repartirse de forma desigual.

Otra ilustración del mismo artículo divide los chasis de una red Clos en cuatro grupos para actualizarlos por turnos. Desactivar uno deja un 56,25 % de capacidad, porque las pérdidas se combinan entre niveles. Ocho grupos suavizan el procedimiento, a costa de prolongarlo. No es el ejemplo de los cuatro bloques independientes de Freedom y no se pueden intercambiar sus porcentajes.

La diferencia obliga a definir el tamaño de una intervención por la conectividad que queda, no por la proporción de cajas que sale del servicio. El procedimiento y la topología forman parte de la misma decisión.

Lo que los bloques siguen compartiendo

Para Firehose, Watchtower y Saturn, los autores describen Firepath: distribuye un estado común de topología y enlaces, mientras los conmutadores calculan localmente sus tablas de reenvío. La coordinación es lógicamente centralizada, no una elección central de la ruta de cada paquete. Instancias de control redundantes y una red aparte sostienen ese esquema. Los detalles de control de Jupiter quedan expresamente fuera del alcance del artículo.

Antes de Jupiter, unos pocos parámetros de clúster producían también listas de materiales, planes de racks y cables, información de monitorización y configuraciones comunes. Restringir opciones ayudaba a repetir la construcción. A cambio, aumentaba la importancia de que la especificación compartida fuese correcta.

Las experiencias operativas ponen límites a esa comodidad. Un reinicio simultáneo de la red hizo competir las comprobaciones de actividad y el cálculo de rutas por la CPU limitada de los conmutadores. El envejecimiento de enlaces internos y de control expuso estados insuficientemente vigilados. En Freedom, una lectura concurrente sin bloqueo interactuó con un cambio de configuración BGP y dejó una configuración parcial. El equipo relata la reversión y el refuerzo de sus herramientas.

Son mecanismos históricos descritos por el operador. Los pasajes no ofrecen duraciones, perjuicios a clientes ni una tasa general de interrupciones. La separación de equipos seguía necesitando observación y cambios de software seguros para ser útil.

La capacidad de cambiar

La edición de SIGCOMM de 2015 y la publicación en CACM de 2016 corresponden al mismo trabajo, no a dos verificaciones independientes. Su detalle permite analizar el aprendizaje, pero no certificar la implementación actual.

La aportación que esta historia permite asociar a Hölzle es una responsabilidad de infraestructura documentada junto a una labor colectiva: hacer que una red enorme admita intervenciones acotadas. El resultado no se mide únicamente por lo que conecta cuando todo está disponible. También por qué permanece conectado, observable y recuperable cuando una parte debe salir.

Fuentes