Evolucionar o morir: principios de diseño de alta disponibilidad

Extraído de la infraestructura de red de Google

Ramesh Govindan † Ina Minei †, Mahesh Kallahalla †, Bikash Koley †, Amin Vahdat †
† Google * Universidad del Sur de California
Índice.
Resumen
1. Introducción.
2. Red de Google.
3. Desafíos de disponibilidad.
3.1 Objetivos de la disponibilidad de red.
3.2 Desafíos
3.3 Mecanismos de disponibilidad de referencia
4. Informes Post-Mortem
5. Análisis de fallos
6. Categorías de causa raíz
6.1 Categorías del plano de datos
6.2 Categorías del plano de control
6.3 Categorías del plano de gestión
7. Principios de alta disponibilidad
7.1 Utilice la defensa de profundidad
7.2 Mantener la coherencia dentro y entre planos
7.3 Fallo de apertura
7.4 Una onza de prevención
7.5 Recuperarse rápido
7.6 Actualice continuamente la red
Resumen
Mantener los niveles más altos de disponibilidad para los proveedores de
contenido es un desafío frente a la escala, la evolución de la red y la
complejidad. Sin embargo, se sabe poco acerca de las fallas de red a las que
son susceptibles los grandes proveedores de contenido y de los mecanismos
que emplean para garantizar una alta disponibilidad. A partir de un análisis
detallado de más de 100 eventos de fallas de alto impacto dentro de la red
de Google, que abarca muchos centros de datos y dos WAN, cuantificamos
varias dimensiones de fallas de disponibilidad. Descubrimos que las fallas
se distribuyen uniformemente entre los diferentes tipos de redes y entre los
planos de datos, control y administración, pero que ocurren una gran
cantidad de fallas cuando una operación de administración de la red está en
progreso dentro de la red. Analizamos algunos de estos fallos en detalle, y
también describir nuestros principios de diseño para alta disponibilidad
motivados por estos fallos. Estos incluyen el uso de la defensa en
profundidad, el mantenimiento de la coherencia en todos los planos, la
apertura de fallas grandes, la prevención y evitación cuidadosas de fallas y
la evaluación de la causa raíz rápidamente. Nuestros hallazgos sugieren
que, a medida que las redes se vuelven más complejas, las fallas acechanen
todas partes y, contrariamente a la intuición, la evolución incremental
continua de la red puede, cuando se aplica junto con nuestros principios de
diseño, dar como resultado una red más robusta.
Conceptos de CCS
• Redes! Algoritmos de ruta de control; Fiabilidad de la red;
Capacidad de gestión de la red;
Palabras clave
Disponibilidad; Plano de control; Plano de gestión
1. INTRODUCCIÓN
Los proveedores de contenido a escala mundial ofrecen una variedad de
servicios cada vez más populares que van desde la búsqueda, el intercambio
de imágenes, las redes sociales, la difusión de videos, las herramientas para
el intercambio en línea.
El permiso para hacer copias digitales o impresas de todo o parte de este
trabajo para uso personal o en el aula se otorga sin cargo siempre que las
copias no se hagan o distribuyancon fines lucrativos o comerciales y que
las copias lleven este aviso y la cita completa en la primera página. . Deben
respetarse los derechos de autor de los componentes de este trabajo que
sean propiedad de terceros que no sean los autores. Se permite resumir con
crédito.
SIGCOMM '16, 22 al 26 de agosto de 2016, Florianópolis, Brasil
© 2016 Los derechos de autor pertenecen al
propietario / autor (es). ISBN 978-1-4503-4193-
6 / 16/08. . . $ 15.00
Laboracion, mercados en línea y servicios en la nube. Para respaldar estos
servicios, construyen centros de datos y WAN con un alcance global, tanto
para interconectar sus centros de datos como para lograr laproximidad del
cliente. Los proveedores optimizan sus redes para proporcionar un alto
rendimiento, baja latencia y alta disponibilidad.
Algunas o todas estas características se correlacionan con un aumentode
los ingresos [ 3 , 23 ].
Si bien se ha escrito mucho sobre el diseño y el rendimiento de la
red de proveedores de contenido [ 18 , 35 , 6 , 11 ], se sabe poco sobrelos
desafíos de disponibilidad de la red que enfrentan los
proveedores de contenido. ¿Qué tipo de garantías de disponibilidadse
esfuerzan por lograr los proveedores de contenido? ¿Qué desafíos
enfrentan para cumplir con estas garantías? ¿A qué tipo defallas son
susceptibles? ¿Cómo logran una alta disponibilidad ante estos fallos? Este
documento arroja luz sobre algunas de estas preguntas basándose en la
experiencia operativa en un gran proveedor de contenido, Google.
Google ejecuta tres tipos de redes cualitativamente diferentes (Sección
2 ): redes de centros de datos, diseñadas a partir de conmutadores de
silicio comerciales, con un plano de control lógicamente centralizado; una
WAN definida por software llamada B4 que admite múltiples clases de
tráfico y utiliza ingeniería de tráfico centralizada; y otra WAN global
llamada B2 para el tráfico de cara al usuario que emplea ingeniería de
tráfico descentralizada. Nos esforzamos por mantener una alta
disponibilidad en estas redes: por ejemplo, para el tráfico de cara al
usuario, el objetivo de disponibilidad interna de Google no es más que
unos minutos de inactividad por mes.
Mantener esta alta disponibilidad es especialmente difícil por tres
razones (Sección 3.2 ). El primero es escala y heterogeneidad: La redde
Google abarca todo el mundo y, a esta escala, la falla de algún componente
de la red es común [ 9 ]. El segundo es velocidad de evolución: la red
cambia constantemente en respuesta a la creciente demanda de tráfico, así
como al despliegue de nuevos servicios. El tercero es complejidad de la
gestión: mientras que el plano de control ha ido evolucionando para hacer
frente a la complejidad de la red, el plano de gestión [ 12 ] no ha seguido el
ritmo.
A pesar de estos desafíos, nuestra infraestructura de red y nuestros
servicios brindan algunos de los niveles de disponibilidad más altos de la
industria en docenas de servicios individuales. Hemos mantenido esta
disponibilidad a pesar de experimentar varios eventos de fallas sustanciales.
Ejemplos de tales fallas incluyen un solo error que elimina la conectividad
a un centro de datos, una falla de tarjeta de línea única que elimina un
enrutador de red troncal completo y una sola configuración incorrecta que
resulta en la falla completa del plano de
control de una WAN. Documentamos cuidadosamente (en Post mortem informes)y
la causa raíz de cada nueva falla significativa,

y también dibujar principios para evitando, localizando, y recuperándose
de fallas, de modo que las fallas posteriores son poco probables y las que
ocurren rara vez son visibles para nuestros usuarios finales.
Contribuciones. En este artículo, hacemos tres contribuciones analizando
más de 100 Post mortem informes de únicos 1 fallas de alto impacto
(Sección 4 ) en un plazo de dos años. Primero, presentamos un análisis
cuantitativo de diferentes dimensiones de fallas de disponibilidad en Google
(Sección 5 ). Descubrimos que la tasa de fallas es aproximadamente
comparable en los tres tipos de redes que tenemos (redes de centros de
datos, B2 y B4). También encontramos que cada una de estas redes es
susceptible a fallas de hardware / plano de datos, así como fallas en el plano
de control y en el plano de gestión. El 80% de las fallas duran entre 10
minutos y 100 minutos, significativamente mayor que los objetivos de
disponibilidad de nuestra red. Casi el 90% de las fallas tienen un alto
impacto: grandes pérdidas de paquetes o agujeros negros en centros de
datos completos o partes de los mismos. Finalmente, encontramos que,
cuando ocurren la mayoría de estas fallas,un operación de gestión estaba en
progreso en las proximidades.
En segundo lugar, clasificamos las fallas por algunas categorías de
causa raíz (Sección 6 ), y descubre que, para cada uno de los planos de
datos, control y gestión, las fallas pueden tener su origen en un puñadode
categorías. Ejemplos de tales categorías incluyen: fallas en la evaluación
de riesgos; falta de coherencia entre los componentes del plano de control;
exceso de recursos del dispositivo; solapas de enlace; operación de gestión
ejecutada incorrectamente; Etcétera.
Cuantificamos la distribución de fallas en estas categorías, pero también
discutimos en detalle las fallas reales dentro de algunas categorías. Esta
categorización es más precisa que simplemente la raíz que causa fallas de
hardware, errores de software o errores humanos, lo que nos permiteextraer
lecciones importantes para mejorar la disponibilidad de la red.
En tercer lugar, discutimos principios de diseño de alta disponibilidad
extraídas de estas fallas (Sección 7 ). Nuestro análisis cualitativo y la
categorización de la causa raíz sugieren que ningún mecanismo o técnica
puede solucionar una fracción significativa de las fallas de disponibilidad de
Google. Primero, defensa en profundidad
es necesario para detectar y reaccionar ante fallas en diferentes
capas y planos de la red y se puede lograr conteniendo el radio de falla y
desarrollando estrategias de respaldo. Segundo, fallarabierto conserva el
plano de datos cuando falla el plano de control. Tercero, manteniendo la
consistencia
en los planos de datos, control y gestión puede garantizar una evolución
segura de la red. Cuarto, una cuidadosa evaluación de riesgos, pruebas y un
plano de gestión unificado pueden prevenir oevitar fallas. Quinto, rápida
recuperación de fallas no es posible sin sistemas de monitoreo de alta
cobertura y técnicas para el análisis de la causa raíz. Al aplicar estos
principios,
Junto con la idea contraria a la intuición de que la red debe evolucionar de
forma continua e incremental, hemos logrado aumentar la disponibilidad
de nuestras redes incluso cuando su escala y complejidad se han
multiplicado por muchas. Concluimos con una breve discusión sobre los
problemas de investigación abierta en el diseño de redes de alta
disponibilidad.
1 Cada informe post-mortem documenta una falla única, nunca antes vista.
Nose documentan instancias posteriores de la misma falla.
Otros ISP
B4
B2
B4BR
B2CR B2CR
B4BR Paquete B2
B4BR
Paquete B4 B2BR B2BR
Cluster Tela
. . .
CARRO s CARRO
Figura Tela
1: Red global de Google
2. RED DE GOOGLE
En esta sección, discutimos un modelo simplificado de la red de
Google. Esta discusión dará contexto para algunas de las descripciones de
fallas en secciones posteriores, pero omite algunos de los detalles por
brevedad.
Las redes. Conceptualmente, la red global de Google, una de las más
grandes del mundo, consta de tres componentes cualitativamente diferentes
(Figura 1 ): un conjunto de campus, donde cada campus alberga una serie
de grupos; una WAN, llamadaB2, que transporta el tráfico entre los
usuarios y los clústeres; y una WAN interna llamada B4 [ 18 ] responsable
también de transportar tráfico entre conglomerados. El fundamento de las
dos WAN y de las diferencias en su diseño se analiza en [ 18 ].
Google, a lo largo de los años, ha diseñado varias generaciones de redes
de clústeres; En nuestra red actual, coexisten múltiples generaciones de
clusters. Estos diseños de clústeres emplean variantes de una topología
Clos de múltiples etapas (ver [ 35 ]), con conmutadoresindividuales que
utilizan generaciones sucesivas de silicio comercial. La capa inferior de la
red Clos consta de conmutadores ToR que proporcionan conectividad a un
bastidor de servidores. Las capas intermedias de la red de Clos, en
diferentes generaciones de tejidos, consistieron en subtejidos agregados de
diferentes tamaños, típicamente llamados superbloques. Las capas
superiores de estos tejidos de agregación comprenden conmutadores
centrales, o agregados de los mismos, llamados bloques de columna.
En una ubicación geográfica determinada o metro, Google puede tener
más de un centro de datos. En generaciones anteriores del diseño de
clústeres de Google, los servidores dentro de un solo centro de datos
estaban interconectados por un solo tejido, y los tejidos dentro de un metro,
a su vez, estaban interconectados a través de un tejido de agregación de
clúster para ofrecer suficiente capacidad dentro del metro. La generación
más reciente puede escalar para interconectar múltiples estructuras de
clúster. Los tejidos de agregación de clústeres ylos tejidos de última
generación, a su vez, se conectan a las dos WAN, B2y B4 a través de
enrutadores de agregación de clúster ( Carros). En las generaciones
anteriores, un CAR era un tejido de agregación independiente y, en sí
mismo, una red Clos de varias etapas. En el tejido de última generación,
algunos de los superbloques o bloques intermedios del tejido se utilizan
como CAR.
Cada CAR se conecta a un interruptor B4 [ 18 ] en un metro llamado B4BR (o
Enrutador de borde B4). Un B4BR en sí mismo es también una red de conmutación de
múltiples etapas, construida a partir de silicio comercial. La
B4 WAN consta de punto a punto manojos entre B4BR en diferentes metros.
Cada paquete es una interconexión compleja entre dos B4BR, diseñada para
lograr una alta capacidad agregada agregando una gran cantidad de enlaces
físicos. El tráfico entre conglomerados en diferentesáreas metropolitanas puede
atravesar varios B4BR, como se describe a continuación.
Cada CAR también se conecta a dos Enrutadores de borde B2 (B2BR).
Estos enrutadores disponibles comercialmente también
proporcionan una capacidad agregada significativa utilizando tejidos de
conmutación internos patentados. La WAN B2 consta de B2BR interconectados
mediante una red de enrutadores de núcleo B2 (B2CR). Los B2CR también se
conectan con enrutadores de borde que se emparejan con los clientes de Google y
las redes de tránsito. Las interconexiones entre todos estos dispositivos también
son paquetes deenlaces físicos 2 proporcionando alta capacidad agregada.
Planos de control y datos. Las tres redes difieren cualitativamente en el diseño de
sus planos de control y datos.Las redes de clúster consisten en un plano de
control lógicamente centralizado responsable de establecer reglas de reenvío en
los conmutadores de estructura. El plano de controlse descompone, por razones
de modularidad del software, en
tres componentes que actúan en concierto entre sí: a Controladorde tejido ( FC) que
calcula rutas dentro de la estructura; a Agentede enrutamiento ( RA) que habla BGP
e IS-IS con los enrutadores
fronterizos vecinos y realiza el cálculo de la ruta IP; y un Controlador
OpenFlow ( OFC) que los programas cambian al interactuar con Agenteusna solicitud: por lo general, el equilibrio de carga de DNS se utiliza para
OpenFlow ( OFA) que se ejecutan en conmutadores individuales.Para lograr esta
programación, la OFC se basa en información de la FC y la RA. El reenvío de
paquetes dentro del tejido utiliza ECMP para utilizar mejor la rica conectividad
de los tejidos Clos.
El plano de control de B4 también utiliza la centralización lógica, pero aplica
esta centralización en dos niveles. Dentro de un B4BR, elplano de control está
organizado como en grupos, que constan de los mismos tres componentes (FC,
RA y OFC) como se discutió anteriormente, y el reenvío del plano de datos usa
ECMP para utilizar mejor la capacidad agregada del enrutador. Sin embargo, en
la WAN B4, el plano de control centralizado tiene una arquitectura diferente
porque la topología WAN es cualitativamente diferente de la de los clústeres.
Específicamente, el plano de control consta de
cuatro componentes que trabajan en conjunto [ 18 , 21 ]; la Puerta deenlace B4
extrae los estados de la red y programa el estado del plano de control en los
B4BR; a Modelador de topología calcula un modelo de la topología WAN actual,
incluidas las limitaciones de capacidad actuales en y entre B4BR, utilizando el
estado de la red extraído de la puerta de enlace; a Servidor TE calcula las rutas TE
a nivel de sitio entre B4BR utilizando el modelo de topología, así como la
demanda de tráfico presentada a la red; y un ejecutor de ancho
de banda ( BwE, [ 21 ]) estima la demanda de tráfico necesaria para elservidor TE y
también aplica la carga ofrecida por las aplicaciones a
límites predeterminados. El plano de datos usa encapsulación ( tunelizaciónp)roveedor, y asegura que el tráfico de alta prioridad permanece en la
para efectuar rutas TE, y el plano de control B4BR traduce una ruta TE a nivel
de sitio en una o más rutas de tejido intra-B4BR, o uno o más paquetes entre
B4BR.
2 En el resto del artículo, usamos el término manojo para denotar una colección
agregada de enlaces físicos, y Enlace para hacer referencia a un enlace físico.
62
Finalmente, el plano de control de la red B2 es similar al de otros grandes ISP.
B2 usa IS-IS internamente, habla E-BGP con CAR, B4BRy pares externos, y
emplea la reflexión de ruta para escalar la diseminación y el cálculo de la ruta
BGP. La mayor parte del tráfico en B2 se diseña utilizando túneles MPLS. RSVP
establece o derriba los túneles y el ancho de banda automático de MPLS [ 27 ]
adapta lascapacidades de los túneles en respuesta a los cambios en la demanda.
B2 usa prioridades MPLS para adaptarse a diferentes clases de tráfico.
Las arquitecturas de carga de trabajo y servicio. Las tres redes
las obras sirven colectivamente a dos tipos de clientes: clientes internos y
servicios de cara al usuario. Los clientes internos utilizan los clústeres para
almacenamiento distribuido y cálculos distribuidos; por ejemplo, losíndices de
búsqueda se almacenan en un almacenamiento distribuido que puede replicarse
en todos los clústeres, y los índices se (re) calculan mediante cálculos
distribuidos que se ejecutan en servidores dentro de los centros de datos. Tanto el
almacenamiento como la computación pueden generar cantidades significativas
de tráfico de red.
Desde la perspectiva de la red, los servicios orientados al usuario pueden
verse como una jerarquía de dos niveles. Frente termina recibir solicitudes de
usuarios; un front-end es un proxy inverso de software y caché que analiza la
solicitud de servicio y determina qué back-end, de muchos, la solicitud debe
equilibrarse con. Los back-end (que suelen tener varios niveles) cumplen la
solicitud y devuelven la respuesta. Los balanceadores de carga determinan a qué
front-end y back-end se envía
equilibrar la carga de las solicitudes de los usuarios al frontend, y un
equilibrador de carga realiza un seguimiento de las solicitudes agregadas y la
carga del back-end. para equilibrar la carga de solicitudesde frontends a
backends. Este diseño permite la ampliación de los servicios en respuesta a la
creciente demanda. Más interesante, el uso de balanceadores de carga
proporciona un nivel de direccionamiento indirecto que permite a los
operadores reconfigurar dinámicamente los servicios en respuesta a la red (u
otras fallas). Por lo tanto, por ejemplo, los front-end o back-end en un clúster
pueden ser drenado (es decir,
los usuarios pueden ser dirigidos a otros front-end o back-end) cuando ocurre
una falla grande. Por último, la latencia es un determinante clave del
rendimiento para los servicios de cara al usuario: la jerarquía de servicios de cara
al usuario permite la proximidad de las interfaces a los usuarios, lo que permite
un acceso de baja latenciaal contenido.
Clasificamos el tráfico en la red de Google en varias clases de
prioridad para satisfacer las diferentes necesidades de calidad de los servicios de
cara al usuario y los clientes internos, y para garantizar que siempre se atienda el
tráfico importante. Por lo general, se asigna una prioridad más alta al tráfico de
cara a los usuarios y una prioridad más baja al tráfico interno. Nuestras WAN
implementan la diferenciación del tráfico de formas ligeramente diferentes: B4
utiliza la cola de prioridad en los conmutadores, junto con el marcado del
tráfico, el control de admisión y la aplicación del ancho de banda en los bordes;
B2 se basa enel marcado de tráfico y la implementación de QoS en el equipo de
ruta más corta al mapear el tráfico de baja prioridad a los túneles de baja
prioridad.
3. DESAFÍOS DE DISPONIBILIDAD
Mantener una alta disponibilidad ha sido, y sigue siendo, unenfoque
importante de la arquitectura y el diseño de redes en
Google.
3.1 Objetivos de disponibilidad de la red
La red se esfuerza por lograr diferentes objetivos de disponibilidad para
diferentes clases de tráfico. Dado que la disponibilidad de la capa de red es solo
un componente del presupuesto de disponibilidad generalde un servicio de
software, la red debe cumplir con un objetivo de disponibilidad bastante estricto,
de solo un pocos minutos al mes
de tiempo de inactividad, para al menos algunas clases de tráfico.
Google rastrea los objetivos de disponibilidad para diferentes clases de
tráfico en escalas de tiempo por minuto. En B4, tenemos suficiente
instrumentación (utilizada para realizar ingeniería de tráfico) para medir
directamente las duraciones de tiempo durante las cuales el ancho de banda
prometido a los servicios no pudo satisfacerse entre cada par de B4BR para
cada clase de tráfico. Para B2 y clústeres, usamos un sistemasimilar a [ 14 ]
para determinar la indisponibilidad por clase de tráfico entre cada par de
conglomerados; nuestro sistema utiliza medidas de ping entre clústeres y puede
eliminar la ambigüedad entre la inalcanzabilidad dentro de los clústeres y la
inalcanzabilidad en las rutasentre los clústeres. Declara que un clúster no está
disponible para una clase de tráfico dada si la pérdida de paquetes para esa
clase de tráfico, desde todas otros grupos, está por encima de un cierto umbral.
3 Restricciones impuestas por objetivos de disponibilidad estrictos. La
3.2 Desafíos
Hay cuatro razones interrelacionadas por las que lograr los objetivosde
disponibilidad es un desafío dentro de la red de Google.
Escala y heterogeneidad. La red de Google se extiende por todo el mundo, está
diseñada para una alta capacidad de entrega de contenido y contiene
dispositivos de una amplia variedad de proveedores de red, además de varias
generaciones de hardware y software desarrollados internamente. La escala de
la red significa que existe una alta probabilidad de que al menos un dispositivo
o componente falle, o algúnsoftware que funcione mal o mal configurado,
dentro de la red en cualquier momento dado. Implementamos explícitamente
dispositivosde dos proveedores, para la heterogeneidad del hardware. La
heterogeneidad también surge de la escala: se necesita tiempo para actualizar la
red, por lo que en cualquier momento, la red puede tener
2-3 generaciones de, por ejemplo, tecnologías de clúster. Si bien la
heterogeneidad garantiza que es poco probable que el mismo problemaafecte a
varios componentes de la red, también puede introducir fragilidad y
complejidad. Los equipos de diferentes proveedores requieren diferentes
procesos de plano de gestión y su software puede actualizarse a diferentes
velocidades. Los chips de silicio comerciales de diferentes generaciones
exponen capacidades ligeramente diferentes que deben abstraerse mediante
software de conmutación, lo que aumenta la complejidad. Esta heterogeneidad
es fundamental, dada nuestra velocidad de evolución (que se analiza a
continuación), e intentamos gestionarla utilizando procesos cuidadosos de
desarrollo y gestión de software.
Velocidad de evolución. El rápido crecimiento del tráfico de propiedad
intelectual mundial (5 ⇥ durante los últimos cinco años, y un crecimiento
proyectado similar [ 8 ]), del cual Google tiene una participación significativa,
requiere una rápida evolución en el hardware y software de red en Google. Esta
velocidad de evolución se ve acentuada por el crecimiento en la cantidadde
productos que ofrece Google. Esta velocidad, acoplada
3 El umbral de pérdida varía según la clase de trá fi co entre 0,1% y 2%.
63
con escala, implica que, con alta probabilidad, el software o el hardware de
alguna parte de la red se actualiza todos los días, lo que puede exacerbar
aún más la fragilidad.
Complejidad de la gestión de dispositivos. Un tercer desafío en Lograr una
alta disponibilidad es la complejidad de administrar dispositivos dered
modernos, especialmente en niveles más altos de agregación. Por ejemplo,
en 2013, Google empleó varios chasis de 1,28 TB / s en su WAN [ 18 ].En la
actualidad, algunos dispositivos disponibles comercialmente admiten 20
TB / s [ 19 ]. En respuesta al aumento de la agregación, las arquitecturas
del plano de control han logrado escalar abstrayendo y separando el
control del plano de datos, pero los paradigmas de administración no han
seguido el mismo ritmo y, por lo general, siguen considerando la red como
una colecciónde dispositivos administrados independientemente. Por
ejemplo, la mayoría de las herramientas de administración aún permiten la
configuración basada en CLI, lo que hace que las secuencias de comandos
y la automatización sean propensas a errores, y las herramientas de
administración exponen la administración a la granularidad de dispositivos
individuales o chips de conmutadores individuales en un B4BR.
Los objetivos estrictos de disponibilidad de unos pocos minutos al mes
también pueden presentar un desafío imponente. Por ejemplo, en
algunos
casos, la actualización de un enrutador de borde puede llevar más de 8 horas.
Un proceso de actualización tan largo introduce una ventana de
vulnerabilidad afallas concurrentes. Para evitar fallas durante las
actualizaciones planificadas, podríamos drenar los servicios de los clústeres
afectados, pero si hiciéramos esto para cada actualización, dada la velocidad
de nuestra evolución, podría afectar nuestra capacidad de servicio. Los
servicios de drenaje manual
también pueden ser propensos a errores. Por lo tanto, muchas
actualizacionesplanificadas deben actualizar en el lugar, lo que también
puede aumentar la fragilidad de la red.
3.3 Mecanismos de disponibilidad de referencia
Al comienzo de nuestro estudio, la red de Google empleóvarias técnicas
avanzadas para garantizar una alta disponibilidad de la red. Todos estos
mecanismos están en en la actualidad también, pero algunos de ellos han
evolucionado y se han implementado mecanismos adicionales, basados en
la experiencia obtenida de las fallas de disponibilidad descritas en el resto
del documento.
Primero, nuestros clústeres y topologías WAN se planifican
cuidadosamente para adaptarse a la demanda proyectada. También
diseñamos nuestra red para tolerar fallas de componentes clave como
motores de enrutamiento, fuentes de alimentación o ventiladores en
dispositivos individuales, así como fallas de paquetes o dispositivos,
mediante el uso de B2BR y B2CR redundantes. Para ser resistentes a las
fallas físicas de la planta, utilizamos fibras físicas disjuntas y
alimentadores de energía disjuntos.
En segundo lugar, cada componente del plano de control lógicamente
centralizado (desde FC, RA y OFC en las estructuras hasta BwE, Gateway,
TE Server y Topology Modeler) se replica con replicación maestro /
esclavo y conmutación por error transparente. Las réplicas del plano de
control WAN se colocan en ubicaciones geográficamente diversas. En B2,
utilizamos la protección MPLS para lograr un redireccionamiento rápido
en caso de fallas, y el ancho de banda automático MPLS para adaptar
automáticamente las reservas del túnel a las fluctuaciones fluctuantes.
mand [ 27 ].
En tercer lugar, tenemos un proceso de aprobación o fi nal mediante el cual los
servicios se registran para prioridades de tráfico específicas. Los desarrolladores de
servicios reciben pautas sobre qué tipos de tráfico deben utilizar qué prioridad y deben
especificar las demandas de tráfico al solicitar laaprobación de una prioridad. Una vez
que se concede la aprobación a un servicio para una demanda específica, BwE marca
el tráfico del servicio con la prioridad adecuada y limita la velocidad del tráfico.
En cuarto lugar, tenemos varios procesos del plano de gestión diseñados para
minimizar el riesgo de fallas. Usamos pruebas de regresión antes de implementar
actualizaciones de software e implementarlas ca- naries a escalas más pequeñas antes de
implementarlo en toda la red. También realizamos periódicamente escenarios de desastre [
20 ,
17 ] y mejorar nuestros sistemas basándose en las lecciones de estos ejercicios.
Documentamos cuidadosamente cada operación de gestión MOp) en la red. Algunos
ejemplos de MOps incluyen la implementación de un nuevo softwarede plano de
control, la actualización de enrutadores o paquetes, la instalacióno sustitución de
componentes como tarjetas de línea, transmisores ópticos o firmware de conmutador.
La documentación de cada MOp enumera los pasosnecesarios para la operación, una
duración estimada y un Evaluación de riesgos sobre la probabilidad de que el MOp
afecte los objetivos de
causas fundamentales de la falla. A partir de estas descripciones,
disponibilidad. Si un MOp se considera de alto riesgo, los operadores drenar servicios
afectados antes de ejecutar el MOp.
4. INFORMES POST-MORTEM
En Google, tenemos un proceso mediante el cual documentamos cada gran
falla en un informe post-mortem e identificar lecciones de la falla, de modo que
se pueda evitar o mitigar su recurrencia. Como tal, cada informe post-mortem
identifica una falla que afectó los objetivos dedisponibilidad discutidos
anteriormente, que llamamos un evento de falla. El informe incluye la ubicación
de la red de la falla, su duración y su impacto en los volúmenes de tráfico y las
tasas de pérdida de paquetes, así como el impacto en los servicios. Está coescrito
por miembros de diferentes equipos cuyos sistemas fueron impactados o
causados por elevento de falla. Contiene una línea de tiempo de los eventos (si se
conocen) que llevaron a la falla, y la línea de tiempo de los pasos tomados para
diagnosticar y recuperarse de la falla. También contiene una caracterización
precisa de la (s) causa (s) raíz (s) de la falla. Un solo evento de falla puede tener
más de una causa raíz; los operadores e ingenieros confirman estas causas raíz
reproduciendo la falla, o partes de la misma, ya sea en el campo o en un
laboratorio. Muchos de los informes también incluyen diagramas detallados que
dan contexto, a una audiencia más amplia, del fracaso. Finalmente, los informes
contienen una lista de elementos de acción para realizar un seguimiento de la
falla, que puede variar desde cambios en el software o la configuración hasta
cambios en los procesos del plano de gestión. Cada elemento de acción suele ser
objeto de seguimiento y debate en un sistema de seguimiento de errores.
El proceso de redacción de una autopsia es libre de culpas y sin
prejuicios. Los compañeros y la gerencia revisan cada autopsia para
verificar que esté completo y sea preciso [ 5 ]. Estoasegura que
aprendamos las lecciones correctas de la falla y evitemos futuras
ocurrencias de la misma falla. Además, no todas las fallas de
disponibilidad se documentan en una autopsia; Si una falla es la
recurrencia de otra falla para la cual se redactó un informe post-
mortem, no se documenta porque
64
No hay nuevas lecciones que aprender de este fracaso.
Conjunto de datos. En este documento, hemos recopilado y analizado todos los
informes post-mortem (103 en número) de fallas de red en Google durante los
últimos dos años. En el resto del documento, presentamos un análisis de este
conjunto de datos, describimos algunos de los eventos de falla para darle al
lector alguna intuición sobre la magnitud y complejidad de nuestras fallas de
disponibilidad, y concluimos con una discusión sobre los principios de diseño
extraídos deestos. fracasos.
5. ANÁLISIS DE FALLOS
Por Red y Plano. Figura 2 muestra la distribución de eventos de falla en las
tres redes. No domina una sola red y los eventos de fallas ocurren con una
frecuencia comparable 4 en las tres redes.Los clústeres ven la mayoría de las
fallas (más de 40), pero B4 vio más de 25 fallas. Esto implica que no existe
un tipo de red objetivo natural para enfocar nuestros esfuerzos de mejora
de la disponibilidad.
Los informes post-mortem también incluyen una discusión de las
atribuimos los eventos de falla a uno de tres planos: datos, control y
administración. Las fallas del plano de datos incluyen fallas de hardware y fallas
debido a limitaciones del dispositivo o del sistema operativo. Las fallas del
plano de gestión son aquellas que podrían atribuirse a un MOpen proceso, y las
fallas del plano de control son el resultado de una propagación incorrecta del
estado u otras interacciones no deseadas entre los componentes del plano de
control.
A veces, atribuir fallos a los aviones requiere un juicio informado.
Por ejemplo, cuando un evento de falla tuvo múltiples causas raíz ( p.ej,
una falla de enlace desencadenó un error en el plano de control),
¿fue esto un plano de datos o una falla del plano de control? En el ejemplo
anterior, atribuimos la falla al plano de control, ya que podría decirse que el
plano de control debería haber sido robusto a las fallas de enlace. Sin
embargo, si una falla de enlace coincidió conla operación de mantenimiento
de la red planificada que debería haber sido segura debido a la redundancia
pero causó una pérdida congestiva, atribuimos la falla al plano de datos.
Figura 2 también muestra la distribución de eventos de falla
en los planos por red. Las tres redes son susceptibles a fallas enlos
planos de control, datos y administración y ningún plano domina
ninguna red, con la posible excepción de B4 donde las fallas en el
plano de control superan las fallas en el plano de datos y
administración en conjunto. Por lo tanto, las mejoras dedisponibilidad
deben apuntar a los tres planos.
Por elemento estructural. Nuestras redes tienen muchos
elementos estructurales: tejidos, ToR, CAR, B2BR, etc. Figura 3 muestracómo se
distribuyen los eventos de falla entre estos elementos estructurales. Hay cinco
elementos estructurales, cada uno de
los cuales es responsable de 10 eventos de falla o más. LosB2BR,
los CAR y los tejidos ocupan posiciones críticas en la topología, y
cualquier falla en estos puede resultar en una disponibilidad
degradada. Otros dos puntos de dolor en el
4 Nuestros informes post-mortem solo documentan único fracasos, no todas fracasos. Comotal,
usamos el término frecuencia para referirnos a la frecuencia de ocurrencia de fallas únicas. También
por esta razón, no hemos analizado la frecuencia de eventos de falla a lo largo del tiempo, porque no
tenemos datos para todos los eventos.

Modelador de topología
Grupo
Elemento de red
Control
La red
B4
Datos
Gestión
B2
0 10 20 30 40
Recuento de eventos de falla
Figura 2: Distribución de fallas
eventos en avión y red
la red son menos obvias. Los ToR son la fuente de muchas fallas en gran
parte como resultado de fallas causadas por actualizaciones de software
defectuosas que ocurren simultáneamente en múltiples ToR. El software
ToR evoluciona con relativa rapidez, por lo que contribuyen en gran
medida a la indisponibilidad de la red. Usamos una red de plano de control
fuera de banda para las estructuras y B4, y las fallas en esta red pueden
tener un impacto significativo en los planos de control y, por lo tanto, en la
disponibilidad. De los componentes del plano de control de toda la red,
BwE representa un número notable de eventos de falla.
Impacto. Los eventos de falla impactan directamente los objetivos de
disponibilidad, y podríamos haber medido la disponibilidad de la red,
pero losinformes post-mortem no describen todas fallas de disponibilidad,
solo grandes. Por esta razón, clasificamos los eventos de falla en seis
clases de impacto diferentes: agujeros negros, donde el tráfico hacia un
conjunto de objetivos, o de un conjunto de fuentes, estaba completamente
bloqueado; pérdida de paquetes alta / baja para tráfico de alta prioridad;
pérdida alta / baja de paquetes en el tráfico para tráfico de menor prioridad;
y sin impacto (discutido a continuación). Para distinguir la pérdida de
paquetes alta / baja, usamos los umbrales de pérdida usados para los
objetivos de disponibilidad para el tráfico de alta y baja prioridad.
Figura 4 muestra la distribución de eventos de falla en estas
categorías. Nuestros eventos de falla a menudo tienen un gran impacto, con
más de 30 eventos de falla que resultan en agujeros negros de tráfico, a
menudo para grupos completos a la vez. También ocurren con frecuencia
altas pérdidas de paquetes que resultan en sobrecargas de la red debido a
fallas, en todas las clases de tráfico. Un pequeño número deeventos de falla
no tienen impacto: en estos eventos, a menudo, se descubrió una falla
latente, pero los operadores esperaron para solucionarla porque no
representaba una amenaza inmediata. Todas las redes son susceptibles a
categorías de alto impacto (agujeros negros y alta pérdida de paquetes), con
la excepción del tráfico de alta prioridad en B4, que no transporta ese
tráfico.
Duración. La duración de un evento de falla representa el tiempo desde que
se descubrió por primera vez hasta que se completó la recuperaciónde la
falla. En algunos eventos de fallas grandes, como aquellos en los que el
tráfico hacia y desde un clúster completo tiene agujeros negros, los
operadores primero drenan todo el clúster ( es decir,
reconfigurar el balanceador de carga para que deje de enviar trá fi co a
Colina
Alta prioridad / baja pérdida
Puerta
Alta prioridad / alta pérdida
Tela
CPN
Severidad de la falla
Prioridad baja / Pérdida baja
CARRO
B2
B4
BwE Grupo
Prioridad baja / Pérdida alta
B4BR
Paquete B4
Sin impacto
B2CR
B2BR
Blackhole
Paquete B2
0 5 10 15 0 Contar 10 de Fai2l0ure inclus3o0 ts
Recuento de eventos de falla
Figura 3: Distribución de fallas Figura 4: Distribución de fallas
eventos por elemento estructural eventos por impacto y red
Servicios que se agrupan, prefiriendo instancias de servicios en otros
clústeres) antes de comenzar a causar la falla e iniciar la recuperación. En
estos casos, la duración mide cuándo se solucionóla falla ( p.ej, el agujero
negro fue reparado). La reanudación del servicio después de tales fallas a
veces puede llevar mucho más tiempo ( p.ej, debido al retraso para que la
replicación de datos se ponga al día), por lo que no lo incluimos en la
duración del evento. Para otros eventos de falla, los operadores intentan
reparar la falla sin agotar los servicios; En estos casos, la duración mide el
tiempo durante el cual los efectos de la falla ( p.ej, pérdida de paquetes)
eran evidentes.
Figura 5 traza la CDF de la duración de los eventos de falla por red.
Aproximadamente el 80% de todos nuestros eventos de falla tuvieron una
duración de entre 10 minutos y 100 minutos. Cuando se mide contralos
objetivos de disponibilidad discutidos en la Sección 3.2 , donde el objetivo
del tráfico de alta prioridad era unos minutos de inactividad por mes, estos
números cuantifican los desafíos que enfrentamos para mantener una alta
disponibilidad dentro de nuestras redes. Los eventos de falla cuya duración
fue inferior a 10 minutos se beneficiaron de la experiencia del operador en
el diagnóstico de la causa raíz o del hecho de que la causa de la falla era
obvia ( p.ej, porque el impacto de la falla sevio después de completar un
paso de un MOp). Las duraciones de falla de más de 100 minutos
generalmente representan eventos que resultaron en niveles bajos de
pérdida de paquetes para tráfico menos importante o, en algunos casos, una
falla latente que se descubrió pero que aún no había afectado a la red. En
estos casos, los operadores optaron por esperar para solucionar el
problema porque se consideró demenor prioridad, ya sea esperando que
los desarrolladores desarrollen yprueben una versión de software, o que los
proveedores envíen una pieza de repuesto.
Finalmente, Figura 5 muestra que, a nivel de distribución, los eventos
de falla en B2 y los clústeres son de menor duración que en B4 (tenga en
cuenta que el eje x es escala logs), probablemente porque las dos primeras
redes transportan tráfico de alta disponibilidad, pero B4 no.
El papel de la evolución en los eventos de fracaso. Hemos dis-
Consideramos que uno de los principales retos para mantener la alta
disponibilidad es la constante evolución de nuestras redes. Estaevolución
implica la implementación frecuente de software nuevo, errores de
software, MOps frecuentes en la red y actualizaciones.
65
al equipo de red. En consecuencia, clasificamos los eventos de falla
según si el evento fue causado por un error de software y si una
actualización, un cambio de configuración, un MOp o una
implementación de software estaba en progreso en el momento de la
falla. Estas categorías no son mutuamente excluyentes ya que las
actualizaciones, configuraciones y lanzamientos de software son formas
específicas de MOps; Agregamos estas dos categorías para resaltar el
papel que juega la evolución de la red en los eventos de falla.
Figura 6 muestra cómo estas formas de evolución o sus resultados ( p.ej,
errores) se distribuyen en diferentes redes. Casi 70 de los eventos de
falla ocurrieron cuando un MOp estaba en progreso en el elemento de
red donde ocurrió la falla. Para dar un contexto para este resultado y la
tasa de evolución en nuestra red: en una semana típica el año pasado, 58 5
Los MOps de red se programaron dentro de Google. Es posible que
AMOp no siempre sea la causa raíz del evento de falla. Los errores
en el software representan cerca de 35 fallas, y otras categorías de
evolución se observan en menor grado (pero en números
significativos) y en todas las redes.
6. CATEGORÍAS DE CAUSA RAÍZ
Además de caracterizar los eventos de falla por duración, severidad y
otras dimensiones, también los hemos clasificado por categoría de causa
raíz. 6 La causa raíz de un evento de falla es aquella que, si no hubiera
ocurrido, el evento de falla no se habría manifestado. Un solo evento de
falla puede tener múltiples causas, como veremos más adelante. Para un
evento de falla dado, la causa raíz se determina a partir de los informes
post mortem. Las causas fundamentales de los eventos de fallas
individuales por sí mismas no proporcionan mucha información, por lo
que clasificamos las causas fundamentales en diferentes categorías,
Figura 7 .
La categorización de las causas raíz puede ser subjetiva. Todas las
causas raíz de las fallas de la red se pueden clasificar en fallas de
hardware, errores de software y errores de configuración, pero, a partir
de esta categorización burda, es más difícil derivar conocimientos
específicos sobre cómo contrarrestar estas causas raíz, más allá de las
sugerencias genéricas para agregar redundancia de hardware,
endurecimiento del software y evitación de errores de configuración. Por
lo tanto, utilizamos una categorización detallada de las causas raíz que
brindan información útil sobre el aumento de la disponibilidad de la red.
Nos queda un trabajo futuro para explorar si otras categorizaciones
podrían haber arrojado diferentes conocimientos.
Causa raíz por red. Antes de discutir algunas de las categorías de causa
raíz en detalle, presentamos la frecuencia de ocurrencia de cada
categoría y su desglose por red (Figura 7 ). Algunas categorías de causa
raíz se manifiestan con más frecuencia en eventos de falla que otras: la
frecuencia varía de 2 a 13 en nuestro conjunto de datos. Algunas
categorías de causa raíz ocurren exclusivamente en un tipo de
5 A partir de este número, sería incorrecto extrapolar la fracción de MOps que
conducen a fallas. Nuestro único documento post-mortems único fallas, y este
número no incluye MOps automatizados que a veces no están documentados
para su revisión.
6 Una categoría de causa raíz corresponde aproximadamente, en la literatura sobre sistemas de
confiabilidad, a un culpa tipo. Sin embargo, una falla generalmente se define como un error de
software o una falla de hardware [ 10 ], pero nuestras categorías de causa raíz incluyen operaciones
incorrectas en el plano de gestión, por lo que hemos evitado utilizar el término
culpa.
66
la red ( p.ej, cascada de elementos del plano de control en B4), y
algunos en dos redes ( p.ej, falla de la red del plano de control).
Estos surgen de las diferencias de diseño entre las tres redes. Sin
embargo, al menos seis de nuestras categorías de causa raíz se
manifiestan al menos una vez en las tres redes, y esto, en algunos
casos, indica problemas sistémicos. Finalmente, las categorías de
causa raíz se distribuyen aproximadamente de manera uniforme en
los diferentes planos (no se muestran): 6 planos de datos, 7 planos
de control y 6 categorías de planos de gestión.
6.1 Categorías del plano de datos
Exceso de recursos del dispositivo. Varios eventos de falla, en las tres redes, pueden
atribuirse a problemas que surgen de la insuficiencia de recursos de hardware o del
sistema operativo. Desde hace muchos años, se sabe que los enrutadores de
Internet fallan cuando se les inyectan tablas de enrutamiento cuyos tamaños
exceden la memoria del enrutador [ dieciséis ]. Pero, se han producido
desbordamientos de recursos más sutiles en las redes de Google, como muestra este
ejemplo.
Más de 1. Una secuencia compleja de eventos en un clúster desencadenó una limitación
latente de recursos del dispositivo. Los operadores drenaron un enlace de fábrica y estaban
realizando pruebas de errores de bits en el enlace. En Google se utilizan varios tipos de
drenaje de enlaces: reducir la preferencia de un enlace, por lo que el tráfico se lleva a cabo
en el enlace sólo cuando se cargan otros enlaces; asignar un enlace de costo infinito para
que aparezca en la tabla de enrutamiento, pero no transmita tráfico; o deshabilitar las
interfaces correspondientes. Estas opciones intercambian velocidad o capacidad por
seguridad: las operaciones menos riesgosas se pueden drenar reduciendo la preferencia,
por ejemplo, y estos drenajes se pueden eliminar más rápido. Pero estos inducen una
semántica de drenaje compleja que los operadores pueden no comprender. En este caso, los
operadores optaron por la primera opción, por lo que el enlace que se estaba probando
transportaba (y caía intermitentemente, debido a las pruebas) tráfico en vivo. Esto provocó
que los OFA perdieran su conectividad con su OFC. Al pasar a una nueva OFC a través de una
interfaz de flujo abierto (OFE), la OFE emitió una búsqueda de DNS inversa antes de
establecer la conexión. Sin embargo, esta búsqueda falló porque sus paquetes se
descartaban en el enlace con errores y el hilo que realizaba la búsqueda estaba bloqueado.
Pronto, suficientes OFA intentaron realizar una conmutación por error de modo que se
alcanzaron los límites del sistema operativo en subprocesos simultáneos y todo el plano de
control falló. Este evento es notable por otra razón: los operadores tardaron mucho en
diagnosticar la causa raíz porque los recopiladores de datos de monitoreo (para cada clúster,
dos conjuntos de agentes de monitoreo recopilan estadísticas de todos los conmutadores y
servidores) estaban ambos dentro del clúster , y cuando la tela fallaba, la visibilidad en el
sistema se veía afectada. Al pasar a una nueva OFC a través de una interfaz de flujo abierto
(OFE), la OFE emitió una búsqueda de DNS inversa antes de establecer la conexión. Sin
embargo, esta búsqueda falló porque sus paquetes se descartaban en el enlace con errores
y el hilo que realizaba la búsqueda estaba bloqueado. Pronto, suficientes OFA intentaron
realizar una conmutación por error de modo que se alcanzaron los límites del sistema
operativo en subprocesos simultáneos y todo el plano de control falló. Este evento es notable por otra razón: los
Fallo de la red del plano de control. B4 y los clústeres utilizan una salida
de banda red de plano de control CPN). Componentes comoOFC, RA y FC se
comunican entre sí y con OFA a través del CPN, que está diseñado para tolerar
fallas únicas de los enrutadores y conmutadores CPN.
Completo La falla del CPN, donde la falla concurrente de múltiples
enrutadores CPN hizo que los componentes del plano de control no pudieran
comunicarse entre sí, causó tres eventos de falla. Estos eventos resultaron de
una combinación de componente de hardware (tarjetas de línea, motores de
enrutamiento) y operador
 Enrutamiento de configuraciones incorrectas
1,00
B2 Fallo en la evaluación de riesgos
Potenciar B4
Fallo parcial o completo del plano de control
Grupo
Enlace flaps o errores

Falta de sincronización del plano de datos y del plano de control

0,75
Falta de coherencia entre los elementos del plano de control
Desenrollar
Fracción de eventos de falla

Proceso de gestión ejecutado incorrectamente

Categorías de causa raíz

Especificación del proceso de gestión incorrecta / incompleta

Contexto
Ingeniería de tráfico incorrecta
B2 B2
0,50 B4 Fregar
B4 Asimetría o congelación de la tela
Grupo Grupo Exceso de recursos del dispositivo

Fallo (parcial) de la red del plano de control

Retrasos en la convergencia del plano de control

Configuración
Empuje simultáneo del software del plano de control del buggy
0,25
Drenajes / actualizaciones de la competencia

Cascada de elementos del plano de control

Error en la automatización del plano de gestión

Bicho
Marcas de CoS incorrectas
0,00
(Concurrente) fallas de hardware o mala configuración de hardware

10 1000 0 20 40 60 0 5 10
Duración (en minutos) Recuento de eventos de falla Recuento de eventos de falla

Figura 5: CDF de la duración de los eventos Figura 6: Eventos de falla y evolución Figura 7: Desglose del fracaso
de falla por red de la red eventos por causa raíz y red

comportamiento. El resto de los hechos fueron causados por parcial Fallo otros componentes. Discutimos una de esas cascadas.
deCPN, y discutimos uno de esos eventos. Casc-1. Un ejemplo de mala propagación de datos ocurrió durante una
CPN-1. En un B4BR, una falla parcial de CPN condujo a un bloqueo total actualización de red, cuando un paquete WAN entre dos áreas
metropolitanas se estaba migrando de un B4BR a otro B4BR. Este paquete
del tráfico. Cada B4BR contiene tres copias redundantes de los
es un agregado de varios enlaces que se reconfiguraron. Durante este
componentes del plano de control. Durante este evento de falla, uno de los
tiempo, hubo una inconsistencia transitoria entre el enlace ( es decir,
enrutadores CPN para el B4BR fue desactivado para el cableado de energía.
topología) configuración e información de enrutamiento (que usaba la
Los enrutadores CPN ejecutan VRRP [ 15 ] que proporciona la abstracción
topología más antigua). Esta inconsistencia desencadenó un error en el
de un enrutador virtual y falla de forma transparente cuandose desconecta Modelador de topología,que determina si un B4BR origina un prefijo de IP
un enrutador CPN. Sin embargo, el temporizador para esta conmutación o no, según la información de la puerta de enlace B4. El error provocó que
por error fue más largo que el tiempo de espera de actividad entre las varios prefijos de IP se declararan originados en más de un clúster. Este
instancias de OFC redundantes, por lo que dos instancias de OFC origen dual rompió una suposición interna dentro de BwE de que un
detectaron una desconexión mutua y se declararon maestros. Todos los prefijo IP se origina en un solo clúster, por lo que BwE asumió que B4
OFA pudieron hablar con ambos OFC. Esta situación,una instancia de un había fallado y cambió todo el tráfico de B4 de / a varios metros a B2, lo
cerebro dividido [ 30 ], se resolvió mediante un scriptde vigilancia que que resultó en una sobrecarga y la consecuente caída de paquetes.
observa estos eventos multimaestro. Sin embargo, debido a un error de
Falta de coherencia entre los elementos del plano de control. La Los
software, el nuevo maestro OFC tenía un estado inconsistente para los
planos de control lógicamente centralizados en B4 y los clústeres se
conmutadores de puerto (en otras palabras, no pudo reconstruir el estado de
componen de componentes distintos que mantienen piezas diferentes,
la red en el traspaso), lo que resultó en un estado incorrecto del plano de
pero relacionadas, del estado del plano de control. Por ejemplo, en un
datos en los conmutadores, lo que llevó a una gran escala falla en el B4BR.
clúster, el Agregador de rutas (RA) mantiene el estado del protocolo de
El tráfico de los clústeres adjuntos se transfirió a B2, pero esto provocó una
enrutamiento, que el FC usa para calcular el estado de la ruta o el fl ujo.
sobrecarga de capacidad y la consiguiente pérdida de paquetes.
Los errores en estas implementaciones pueden introducir inconsistencias
entre estas partes del estado, que se manifiestan como un estado del plano
Otras categorías. Más allá de estos, hemos encontrado otras cuatro de datos corrupto, lo que resulta en pérdidas de
categoríasde causa raíz del plano de datos: fallas concurrentes de hardware tráfico. En los grupos, muchos de estos son capturados por laboratorio y
o configuraciones erróneas de hardware de interfaces, enlaces, motores de pruebas de campo limitadas, y los que no se detectan son extremadamente
enrutamiento, componentes de conmutación óptica, etc .; malas marcas de difíciles de identificar.

CoS resultante del tráfico marcado incorrectamente para la diferenciación Consis-1. Un evento de falla fue provocado por tal inconsistencia que tardó
basada en clases; asimetría de la tela o se congela resultante de varias semanas en ser la causa raíz. En los conmutadores de clúster, las
mecanismos del plano de datos como ECMP o control de flujo de la capa tablasde reenvío del plano de datos utilizan el siguiente salto grupos
de enlace; errores de enlace o colgajos en el que los errores de bit para implementar ECMP, donde cada grupo identifica un conjunto de
transitorios o las aletas causadas por LACP (IEEE 802.3ad, el protocolo de enlaces sobre los cuales se edita el tráfico con ECMP. El RA, que recibe
control de agregación de enlaces) causan eventos de falla difíciles de información BGP e IS-IS, consulta los conmutadores para los grupos del
diagnosticar. siguiente salto, luego envía las rutas y los grupos del próximo salto
asociados al OFC, que los almacena en su NIB. Para hacer esto, el RA
6.2 Categorías del plano de control
mantiene una copia espejo de los grupos del próximo salto en cada
Cascada de elementos del plano de control. El plano de control de B4 tiene conmutador. Cuando todas las rutas que usan un grupo nexthop son
varios componentes. Varios eventos de falla han resultado en la
propagación de datos incorrectos a través de estos componentes, oen un
componente con cuello de botella que desencadena fallas en

sesenta y cinco
eliminado, idealmente el RA debería purgar su copia de ese grupo
siguiente. Antes de hacer esto, el RA intenta eliminar el grupo nexthop
del conmutador correspondiente, pero si esa operación falla
transitoriamente, el RA continúa almacenando en caché el grupo
nexthop no utilizado. Esta falla en particular fue causada por una
opción de implementación donde, durante
una actualización completa de la tabla de enrutamiento ( p.ej, causadoconmutadores de estructura, volverlos a conectar y apagar otro ( 30%) y
por un reinicio de sesión BGP) la RA no enviaría grupos nexthopno
utilizados a la OFC, que lo eliminaría (correctamente) de su base de
datos. Cuando un anuncio de nueva ruta posterior utilizaba ese grupo
siguiente no utilizado, el RA anunciaba esto a la OFC, que descartaba
la ruta porque no tenía registro del grupo siguiente. Por tanto, las
entradas de la tabla de fl ujo resultantes no se instalarían en los
conmutadores, lo que provocaría un agujero negro. Esta rara secuencia
de eventos sehizo un poco más probable cuando un cambio en la
configuración de enrutamiento hizo que las actualizaciones completas
de la tabla de enrutamiento por parte de la RA fueran mucho más
frecuentes (en este caso, cada vez que cambiaba un atributo de
comunidad en particular). Tales fallas, que resultan en una pequeña
cantidad de entradas de flujo defectuoso,
Otras categorías. Los eventos de falla también surgen de:
concurrente- alquiler de software de avión de control buggy push
para cambiar, ToR, o loscomponentes del plano de control
centralizado en clústeres y B4;
ingeniería de tráfico incorrecta, especialmente en B4, donde, a menudo
debido a errores de modelado, TE Server no distribuye el tráfico por las
rutas disponibles; falta de sincronización entre el plano de datos y el
plano de control, donde un elemento de plano de datos inicia rutas
publicitarias antes de que estas hayan sido completamente instaladas en
los elementos de reenvío; y falla parcial o total del plano de control
donde,especialmente durante un MOp, muchas instancias de
componentes del plano de control fallan simultáneamente tanto en B4
como en clústeres.
6.3 Categorías del plano de gestión
Fallo en la evaluación de riesgos. Antes de planificar un MOp, los
ingenieros evalúan el riesgo asociado con la operación. Esto determina
si, durante la duración del MOp, habría suficiente capacidad residual en
la red para atender la demanda. Si el MOp se considera de alto riesgo,
uno o más servicios se eliminan de los clústeres que se verían afectados
por la reducción de capacidad. Porlo tanto, una evaluación de riesgos
cuidadosa puede permitir actualizaciones de red in situ sin interrupción
del servicio.
Al principio, la evaluación de riesgos era de grano grueso y estaba a
cargo de los operadores, quienes revisarían la descripción del MOp
propuesto y estimarían la capacidad residual por la reducción en la
capacidad del hardware debido al MOp. Por ejemplo, tomar un B2BR
de fline reduce la capacidad en un 50%. En la primera parte de nuestro
estudio, los operadores usarían una regla empírica: una capacidad
residual de menos del 50% se consideraba arriesgada (porque la red
está aprovisionada para fallas únicas).
Posteriormente, las evaluaciones de riesgo se basaron en comparar la
capacidad residual con la demanda histórica. A medida que la red
crecía encomplejidad, estas evaluaciones de grano grueso resultaron
en fallas por varias razones, y fueron reemplazadas por
66
una herramienta automatizada sofisticada.
Riesgo-1. Este evento de falla ilustra la complejidad de estimar la
capacidad residual en una estructura de múltiples etapas durante una
MOp. En este MOp, diseñado para renovar la fuente de alimentación a
una estructura de clúster y programado para durar más de 30 horas,
lospasos requerían apagar selectivamente una fracción fija (30%) de
así sucesivamente. Una evaluación de riesgos simplificada, y la que se
usó para el MOp, predijo una reducción de la capacidad de
aproximadamente un 30%, por lo que los ingenieros consideraron que
laoperación era segura. Desafortunadamente, esto resultó ser
incorrecto: para el diseño de sistema de energía y tejido dado, esta
estrategia en realidad redujo la capacidad en más del 50% y debería
haber requerido que los servicios estuvieran marcados como no
disponibles en el clúster para reducir los niveles de tráfico.
Riesgo-2. Incluso para un solo MOp, múltiples fallas en la evaluación
de riesgos pueden causar fallas. Durante un MOp diseñado para dividir
un B4BR en 2 y programado para durar cinco días, ocurrieron dos
fallas de evaluación de riesgos concurrentes. El primero fue similar a
Riesgo-1: Losingenieros subestimaron la capacidad residual más baja
durante el MOp en un factor de 2. En segundo lugar, fallas
concurrentes en la red en otroLos metros aumentaron la cantidad de
tráfico que transita por este B4BR. Ambos se combinaron para causar
la pérdida de paquetes debido a la capacidad reducida.
Error en la automatización del plano de gestión. Dada la herencia
Debido a la complejidad de las especificaciones de operación del
plano de gestión de bajo nivel y la posibilidad de error humano,
introdujimos laautomatización parcial para las operaciones del plano
de gestión. Esta automatización esencialmente eleva el nivel de
abstracción. Donde antes, por ejemplo, un operador tendría que
actualizar manualmente el software en cada componente del plano de
control en cada uno de los 4 bloques de un B4BR, los scripts
automatizan este proceso. Los operadores todavía están involucrados
en el proceso, ya que un MOp complejo puede involucrar la invocación
de múltiples scripts orquestados por uno o más operadores. Esta
automatización parcial ha aumentado la disponibilidad en general,
pero, debido a que agrega una capa adicional de complejidad, puede
causar grandes fallas en B4 y clústeres. Como resultado de algunas de
estas fallas, estamos explorando abstracciones de nivel superior para la
automatización del plano de gestión, 7.4 .
BugAuto-1. Este evento de falla ilustra la falla en coordinarla
evolución del plano de control y el plano de gestión.
Muchos de estos scripts de automatización están cuidadosamente
diseñados para drenar y desaguar varios elementos de la fábrica en el
orden correcto: interruptores,enlaces físicos, adyacencias de
enrutamiento y componentes del plano de control. En una falla que
ocurrióal actualizar el software del plano de control en 4 bloques del
CAR en un clúster, las adyacencias BGP no aparecieron después de la
ejecución del script, lo que provocó que el clúster se aislara de ambas
WAN. La causa fundamental de esto fue que el script de
automatización había sido diseñado para secuenciar con cuidado los
drenajes y desaguar los drenajes en enlaces físicos,
Secuencia de drenaje / desagüe. Supertrunking se había habilitadoen el
CAR en cuestión, lo que resultó en la falla.
Otras categorías. Otras categorías de causa raíz del plano de gestión incluyen:
enrutamiento de configuraciones erróneas similares a los explorados en
trabajos anteriores [ 29 , 31 ]; desagües o actualizaciones dela competencia
desencadenado por MOps concurrentes y mutuamente
en conflicto; procesos de gestión incorrectos / incompletos donde se utilizó
el conjunto de instrucciones incorrecto durante una operación enun MOp
( p.ej, una operación en un enrutador utilizó instrucciones para un modelo
de enrutador ligeramente diferente); y proceso de gestión ejecutado
incorrectamente en el que un operador humano cometió un error al invocar
interfaces de línea de comandos o scripts de administración.
7. PRINCIPIOS DE ALTA DISPONIBILIDAD
A medida que los sistemas se vuelven más complejos, se vuelven más
susceptibles a fallas imprevistas [ 7 , 32 ]. Por lo
menos En la red de Google, no existe una solución milagrosa, ni un
enfoque o mecanismo único, que pueda evitar o mitigar las fallas. Las fallas
ocurren aproximadamente en la misma medida en las tresredes, en los tres
planos de redes, y no existe una causa fundamental dominante para estas
fallas, al menos según nuestra clasificación. Estos hallazgos nos han
llevado a formular algunas principios de diseño de alta disponibilidad. En
esta sección, discutimos estos principios, junto con los mecanismos
asociados que incorporan esos principios.
7.1 Utilice la defensa en profundidad
Nuestros resultados en la sección 5 muestra que necesitamos defensaen
profundidad 7 para fallas: un enfoque en el que la detección, mitigación o
evitación de fallas se integran en varios lugares o capas dentro de la red.
Contener radio de falla. Los elementos del plano de control redundantes
proporcionan robustez a las fallas de los componentes. En la red de
Google, las fallas simultáneas de todas las réplicas de los elementos del
plano de control no son infrecuentes ( BugAuto-1). Para controlar el
alcance topológico de tales fallas (su radio de la explosión), nosotros (a)
lógicamente dividir la topología de un CAR o B4BR, y (b) asignar cada
partición a un conjunto distinto de elementos del plano de control.
Hay varias opciones para particionar estas topologías de Clos de
múltiples etapas. Una posibilidad es dividir un B4BR en k enrutadores
virtuales, donde cada uno de estos enrutadores virtuales se compone deun 1
/ k- th de los interruptores en ambas etapas. Cada enrutador virtualejecuta
su propia instancia del plano de control, por lo que una falla en uno de
estos enrutadores virtuales solo reduce la capacidad del B4BR en1 / k. Una
ventaja adicional de este diseño es que un enrutador virtual ahora se
convierte en la unidad en la que se ejecutan los MOps, por lo que los MOps
en B4BR se pueden diseñar para minimizar el impacto en la capacidad.
Otras estrategias de particionamiento incluyen aquellas que "colorean"
enlaces e interruptores (Fig. 20 en [ 35 ]) y asignar diferentes colores a
diferentes planos de control.
7 Este término también se utiliza para describir técnicas para proteger
sistemas de software complejos [ 4 ] y tiene su origen en la guerra.
67
Desarrolle estrategias de respaldo. A pesar de estas medidas,
las grandes fallas en toda la red tienen una probabilidad no trivial en la
red de Google. Para mitigar tales fallas, es extremadamente útil tener retroceder
estrategias que ayudan a que la red se degrade con gracia en caso de falla.
Varias estrategias de respaldo son posibles en la red de Google. Cuando
uno o más B4BR fallan, el trá fi co B4 puede retroceder a B2 (como en
Casc-1), donde los CAR envían trá fi co a los B2BR en lugar de alos B4BR.
Por el contrario, cuando todos los B2BR de un sitio fallan, el tráfico puede
diseñarse para volver a B4. En B4, es posible otra forma derespaldo:
cuando el servidor TE falla, el tráfico puede recurrir al enrutamiento IP.
Muchas de estas estrategias de reserva las inician los operadores que
utilizan grandes botones rojos: Controles de software que permiten al
operador activar una recuperación inmediata. Dado el ritmo de evolución
del software del plano de control de Google, diseñamos grandes botones
rojos en cada nueva tecnología que implementamos. Cada vez que se
implementa una nueva función en la red ( p.ej, la abstracción de
supertrunking), la capacidad más antigua se conserva en la red (en nuestro
ejemplo, una maletero abstracción) y control de software (un gran botón
rojo) que se puede utilizar para desactivar la nueva capacidad y recurre a la
anterior.
7.2 Mantener la coherencia dentro y entreplanos
Nuestro segundo principio es mantener la coherencia de estado dentro
del plano de control o entre los planos de datos ycontrol, y la coherencia de
las invariantes de la red en los planosde control y gestión.
Actualice los elementos de la red de forma coherente. Hemos visto varios
Instancias generales en las que errores en el software o en las operaciones
del plano de gestión han dejado elementos de red inconsistentes. En B4 y
clústeres, las inconsistencias entre los elementos del plano de control han
provocado fallas en cascada ( Casc-1), agujeros negros de tráfico difíciles
de depurar ( Consis-1) y el rack se desconecta. Las operaciones de gestión
también pueden dejar un tejido en un estadoinconsistente; en un evento de
falla, un MOp que reconfiguró todos los conmutadores en un CAR dejó dos
conmutadores sin configurar, lo que provocó la pérdida de paquetes.
La sincronización del plano de control y del plano de datos se puede
lograr fortaleciendo la pila del plano de control, ya sea actualizando
sincrónicamente el plano de datos antes de anunciar la accesibilidad, o
esperando a que la estructura converja antes de anunciar la accesibilidad
externa. Para las inconsistencias del estado del plano de control, las
técnicas de análisis de programas [ 25 , 24 ] que determinan Expresar la
equivalencia puede ayudar a detectar algunas de estas inconsistencias. Un
enfoque complementario sería rastrear dinámicamente la equivalencia de
estados. Por ejemplo, el seguimiento de la diferencia en los recuentos de
rutas entre el RA y el OFC podría haber proporcionado una advertencia
temprana de Consis-1. De manera más general, las técnicas automatizadas
para rastrear la procedencia y equivalencia de estados en sistemas
distribuidos son una dirección de investigación interesante. Para el plano
de gestión, las herramientas que determinan si, al final de cada paso
importante de un MOp, el estado de la estructura es coherente, pueden
proporcionar una alerta temprana de fallos. Más generalmente,
transaccional actualizaciones donde se aplica un cambio de configuración
a todos los conmutadores, o ninguno puede ayudar a evitar estas
inconsistencias, pero requiere un diseño cuidadoso de la reversión
estrategias para las operaciones del plano de gestión.
Supervise continuamente las invariantes operativas de la red. La mayoría
de las fallas son el resultado de una o más violaciones de los supuestos de
falla, que se pueden proyectar como invariantes operacionales de la red y
se pueden probar continuamente. Por ejemplo,en B2, usamos Anycast BGP
para proporcionar acceso robusto y de baja
latencia a servicios internos como DNS. Una invariante, no muy conocida,
era que los prefijos anycast deberían tener una longitud de ruta de 3 8 . Un
servicio violó este invariante, provocando una interrupción de nuestro
DNS interno al atraer todo el tráfico de DNS a un clúster. De manera
similar, todas las fallas resultantes de las marcas de prioridad de tráfico
incorrectas violan las asignaciones de servicio a prioridad acordadas
previamente. Más allá de eso, hay muchos otros invariantes en el diseño
del plano de control: enrutadores de emparejamiento que mantienen
sesiones de BGP duales a B2CR, los CAR están conectados a 2 B2BR, los
OFC tienen conectividad redundante a 2 enrutadores CPN.
Desafortunadamente, muchas de estas decisiones a menudo son implícitas
en lugar de establecer explícitamente como un requisito.
Extraer requisitos implícitos e invariantes de diseño del código o las
configuraciones es una dirección de investigación interesante.
Los sistemas de monitoreo para probar estos invariantes deben ir más
allá de simplemente enviar alarmas cuando se viola un invariante; en una
red grande, se pueden activar demasiadas alarmas hasta el punto en que los
operadores dejen de prestarles atención. Más bien, estos sistemas de
monitoreo deben poder agregar estas alarmas (por ejemplo, determinar
cuánto tiempo ha estado ocurriendo una infracción), razonar
continuamente sobre el riesgo que presenta la infracción y presentar a los
operadores una lista priorizada de infracciones o tomar medidas evasivas.
acción para minimizar o evitar elriesgo de fallas por estas violaciones.
A veces, estos invariantes operativos pueden ser violados por un
software de plano de gestión automatizado mal diseñado. En algunas
fallas, el software automatizado apaga todas las réplicas de componentes
del plano de control. Idealmente, el software automatizado debería
haberse negado a violar la invariante de que almenos una instancia de
OFC debe estar ejecutándose.
Requiere tanto lo positivo como lo negativo. Algunos de nuestros fallas
sustanciales resultaron de impulsar cambios en un gran conjunto de
dispositivos, p.ej, un comodín mal configurado que provoca la pérdida de
cientos de dispositivos cuando la intención era drenar dos. Aunque
tenemos controles de cordura para evitar errores humanos, ocasionalmente
también son necesarios cambios amplios. Para MOps con un alcance
potencialmente grande, ahora requerimos dos especificaciones de
configuración separadas para un cambio de red proveniente de dos fuentes
de datos separadas. Drenar una gran cantidad de dispositivos, por ejemplo,
requiere especificar (a) todos los dispositivos que se deben drenar y (b)
una lista explícita y separada de dispositivos que se deben dejar sin drenar.
El software de gestión que realiza el MOp rechaza las configuraciones en
las que hay inconsistenciaentre las dos listas.
8 La razón de esto es interesante: tenemos varias generaciones de diseños
de clústeres en nuestra red, y el número de saltos entre la estructura del
clúster y B2 varía de 1 a 3 según la generación. Unificar la longitud de la
ruta a 3 permite que elproceso de decisión de BGP caiga en el
enrutamiento IGP, lo que permite cualquier difusión.
68
Homogeneidad de gestión con heterogeneidad del sistema.
A lo largo de los años, desarrollamos diferentes sistemas de gestión para
nuestras tres redes. Sin embargo, no había una arquitectura común entre los
tres sistemas, lo que significa que las nuevas técnicas de automatización y
lascomprobaciones de coherencia desarrolladas para una red no se
aplicarían naturalmente a otra. Por lo tanto, estamos trabajando hacia una
arquitecturade administración de red unificada y homogénea con API bien
definidas y modelos de red comunes para operaciones comunes. Esto
promueve el aprendizaje compartido y evita múltiples ocurrencias del
mismo error.
Además, la heterogeneidad del sistema subyacente, especialmente en la
WAN,donde el plano de control y los sistemas de monitoreo son
desarrollados por diferentes equipos, asegura fallas altamente no
correlacionadas: una falla catastrófica en una red es mucho menos probable
que se propague a la otra.
7.3 Fallo de apertura
Un patrón de fallas repetidas que hemos visto es el caso en el que
pequeños cambios en la conectividad física han dado lugar a grandes
inconsistencias en el plano de control. En estos casos, el plano de control
cree rápida e incorrectamente que grandes porciones de la red física han
fallado. Para evitar esto, nuestros sistemas emplean Estrategias a prueba
de fallas para preservar la mayor cantidad posible del plano de datos. cuando
falla el plano de control.
Conserva el plano de datos. La idea detrás de la apertura por falla es simple:
cuando una pila del plano de control falla (por cualquier motivo), no elimina
el estado del plano de datos. Esto conserva el último estado bueno conocido
de la tabla de reenvío de ese nodo, que puede continuar reenviando el
tráfico a menos que haya fallas de hardware ( p.ej, fallos deenlace) que hacen
que la tabla de reenvío sea incorrecta. La apertura por falla se puede
extender a una estructura completa, CAR o B4BR en caso de una falla
masiva del plano de control. En este caso, especialmente si
la falla ocurre dentro de poco tiempo, las tablas de reenvío de
conmutadores serán mutuamente consistentes (nuevamente, fallas de
hardware de módulo), preservando la disponibilidad del tejido o del
dispositivo. La apertura por falla puede ser una estrategia eficaz cuando el
tiempo para reparar el plano de control es menor que el tiempo para la
falla del hardware. Surgen dos desafíos en el diseño de mecanismos
correctos de apertura en caso de falla: cómo detectar que un interruptoro
una colección de interruptores no se ha abierto, y cómo diseñar el plano de
control de pares funcionales (sin fallas) para continuar usando el sistema.
porciones abiertas fallidas de una tela.
Verifique las actualizaciones del plano de control de gran tamaño. En algunos fracasos,
Los elementos del plano de control asumieron de manera conservadora
que si parte de una actualización de estado era inconsistente, era probable
que toda la actualización de estado fuera incorrecta. Por ejemplo, en Casc-
1, Topology Modeler marcó algunos prefijos dentro de la red como
originarios de dos clústeres diferentes. En respuesta, BwE cambió el tráfico
de los conglomerados en varias áreas metropolitanas aB2, asumiendo que
todo B4 había fallado. En otra falla similar, TE Serverinvalidaba de manera
conservadora todo el modelo de topología B4 porque el modelo contenía
una pequeña inconsistencia, como resultadode la superposición del prefijo
IP de un clúster dado de baja que todavía aparecía en la configuración de la
red.
La invalidación de forma conservadora y repentina de grandes partes del
modelo de topología puede, especialmente en una WAN,
afectar los objetivos de disponibilidad. Para preservar la disponibilidad, los
elementos del plano de control se pueden degradar sin problemas (una forma de
apertura en caso de falla) cuando reciben actualizaciones que invalidan o
inutilizan grandes partes de la red. Específicamente, pueden intentar realizar una
validación más cuidadosa y una corrección local de las actualizaciones de estado
para preservar el estado "bueno" del plano de control, por ejemplo, mediante la
inspección de los sistemas de monitoreo. En Casc-1, sistemas de monitoreo que
realizan sondas activas [ 14 ] o proporcionar una interfaz de consulta a las fuentes
BGP detodos los hablantes de BGP en la red podría haberse utilizado para
corroborar (o refutar) el origen del prefijo dual o los prefijos superpuestos entre
grupos. Si se hubieran implementado estos
métodos, el impacto de estas fallas en la disponibilidad habría sidomenor.
7.4 Una onza de prevención
Nuestras experiencias también nos han enseñado que la evaluación continua
de riesgos, las pruebas cuidadosas y el desarrollo de un plano de gestión
homogéneo al tiempo que se conserva la heterogeneidad dela red pueden evitar
fallas o evitar que vuelva a ocurrir la misma falla endiferentes redes.
Evaluar el riesgo de forma continua. En el pasado, las fallas en la evaluación de
riesgos se debían a estimaciones incorrectas de la capacidad ( Riesgo-1), malas
evaluaciones de demanda, cambios en el estado de la red entre el momento en que
se realizó la evaluación de riesgos y el momento en que se realizó el MOp (
Riesgo-2), estados de redintermedios durante MOps que violaron los supuestos
de riesgo, o falta de conocimiento de otros MOps concurrentes.
Las evaluaciones de riesgo deben ser una actividad continua, teniendo en
cuenta la dinámica de la red en curso, y deben realizarse en cada paso del MOp.
Esto requiere un grado significativo de visibilidad en la red (discutido más
adelante), y la automatización junto con la capacidad de revertir un MOp cuando
el riesgo aumenta en el medio de un MOp (por ejemplo, debido a una
concurrencia falla), o la capacidad deagotar los servicios rápidamente. La
evaluación del riesgo de desagües y el riesgo de desagües durante la
recuperación de fallas también son cruciales: en algunas de nuestras fallas, el
acto de drenar los servicios hacausado sobrecargas de tráfico transitorias (debido,
por ejemplo, a que los servicios de almacenamiento concilian las réplicas antes
del desagüe). ), al igual que el acto de vaciarlos.
En general, la evaluación de riesgos debe integrarse estrechamente en el
plano de control de manera que pueda aprovechar el mismo estado y algoritmos
que el plano de control desplegado, en lugar de requerir que los operadores
razonen sobreoperaciones complejas, requisitos de aplicación y estado actual del
sistema. Hemos descubierto que nuestra evaluación de riesgos es
sustancialmente mejor para nuestras redes personalizadas (B4 y clústeres) que
para las construidas con equipos de proveedores (B2), ya que para las primeras
tenemos un conocimiento detallado de exactamente cómo se comporta el drenaje
y el enrutamiento y durante qué tiempo. marcos, mientras que el equipo del
proveedor es más "caja negra". Esto sugiere que, para el equipamiento del
proveedor, las evaluaciones de riesgos pueden mejorarse aumentando la
visibilidad de las operaciones del plano de control y de gestión, lo que permitiría
una mejor emulación del comportamiento del proveedor. o proporcionando
operaciones de drenaje / desagüe de nivel superior con semántica bien
entendida. En los casos en que la semántica de una operación degestión o de un
protocolo particular
69
las opciones de implementación no están claras, la evaluación de riesgosdebería
pecar de sobrestimar el riesgo.
Canario. Debido a que implementamos nuestra propia pila de planos de control,
hemos desarrollado cuidadosos procedimientos internos de prueba y despliegue
para las actualizaciones de software del plano de control y los cambios de
configuración. Muchos de estos procedimientos, como las pruebas de regresión
exhaustivas y las pruebas de laboratorio, probablemente reflejen las prácticas de
otros grandes desarrolladores de software. Más allá de estos, también probamos
versiones de software emulando nuestras redes [ 38 ] a unaescala razonable, tanto
durante el ciclo de desarrollo inicial como antes del lanzamiento.
Finalmente, especialmente para los cambios de software que impactan partes
importantes del plano de control, implementamos cambios de manera muy
conservadora enun proceso que puede llevar varias semanas. Por ejemplo, para
los cambios en el software ToR, podríamos (después de las pruebas de
laboratorio), primero implementarlo en una pequeña fracción (0.1% de los ToR)
en un grupo pequeño (cada implementación de prueba
se llama canario),
luego, fracciones progresivamente más grandes y luego repita el proceso en un
clúster más grande, antes de implementarlo en toda la red. Después de cada
canario, controlamos cuidadosamente el despliegue durante unos días o una
semana antes de pasar al siguiente. Se han producido algunos eventos de falla
durante un canario. Para actualizaciones de componentes del plano de control
replicados como B4Gateway, por ejemplo, actualizamos una réplica a la vez y
monitoreamos el consenso entre las réplicas. Este enfoque nos permitió evitar el
impacto del tráfico en al menos un evento de falla.
7.5 Recuperarse rápido
Un hilo común que atraviesa muchos de los eventos de falla es la necesidad de
encontrar formas de causar la falla rápidamente. Este proceso puede tardar horas,
durante las cuales un clúster puede estar completamente drenado de servicios
(dependiendo de la gravedad de la falla). Los operadores generalmente causan
fallas al examinar (inicialmente) los resultados agregados de dos grandes
sistemas de monitoreo: un sistema de sondeo de ruta activo como [ 14 ], y un
sistemade recopilación de estadísticas pasivo global por dispositivo. Cuando
ocurre un evento de falla, los operadores examinan
cuadros de mando presentados por estos sistemas, busque anomalías (picos
inusuales en las estadísticas o fallas de la sonda) en partes de latopología
cercanas al evento de falla, y use estos indicadores para profundizar en las
causas raíz.
Se han producido retrasos en la raíz que provocan varias fallas por dos
razones. Primero, cuando ocurre un evento de falla, los tableros pueden indicar
múltiple anomalías: en una red grande, no es inusual encontrar anomalías
concurrentes (o, para decirlo de otra manera, la red está siempre en diversos
grados de estado "malo"). Los operadores, varias veces, han profundizado en la
anomalía incorrecta antes de rastrear e identificar la causa raíz correcta ( p.ej,
CPN-2). En segundo lugar, los sistemas de monitoreo a veces no tienen una
cobertura adecuada. Dada la escala del sistema de Googley la complejidad de las
interconexiones de topología, el sistema de sondeo activo a veces carece de
cobertura de rutas y el recopilador pasivo podría no
recopilar ciertos tipos de estadísticas ( p.ej, solapas de enlace) o podría agregar
mediciones y perder transitorios. En ocasiones, una mala ubicación de los
colectores puede dificultar la visibilidad de la red. En general, de cada cluster,
CAR o B4BR,
las estadísticas se recopilan en dos grupos topológicamente distintos. En
algunos de los fracasos ( p.ej, Over-1), los agentes derecopilación de un
CAR estaban ambos en el mismo grupo y, cuando fallaba el CAR, no se
podía acceder a los datos de medición.
Además de depender de sistemas de monitoreo genéricos que pueden
tener que intercambiar cobertura o granularidad por escala, los sistemas de
diagnóstico de causa raíz automatizados pueden ser efectivos para reducir
el tiempo medio de recuperación, mejorando así ladisponibilidad. El diseño
de tales sistemas se encuentra actualmente en exploración.
7.6 ¡Actualice continuamente la red!
Nuestra observación de que tocar la red conduce a fallas de
disponibilidad podría llevar a la siguiente conclusión: limitar la velocidad a
la que evoluciona la red. Esto no es deseable porque: i) la red sería mucho
más cara de lo necesario porque lacapacidad debe aumentarse
significativamente antes de la demanda, ii) la red no admitiría las
características necesarias para soportar las necesidades cambiantes de las
aplicaciones, como baja latencia y robustez control de la congestión, y iii) el
número limitado de operaciones de cambio significaría que la red Trate el
cambio como un evento raro manejado por rutas decódigo que rara vez se
ejercen.
Internamente hemos llegado a la conclusión opuesta. Especialmente en
una infraestructura de red definida por software, y con la creciente
automatización del plano de gestión, existe una oportunidad para hacer
una actualización y cambiar el caso común. Nos esforzamos por introducir
nuevas funciones y configuración en producción cada semana.Esto
requiere capacidad para actualizar la red diariamente, quizás varias veces.
Esto sería necesario, por ejemplo, para abordar ab initio errores, sino
también para respaldar el rápido desarrollo de nuevas funciones en
nuestros bancos de pruebas de laboratorio. La actualización frecuente
también significa que podemos introducir una gran cantidad de
actualizaciones incrementales en nuestra infraestructura en lugar de una
sola "gran explosión" de nuevas funciones acumuladas durante un año o
más. Hemos descubierto que el modelo anterior es mucho más seguro y
también mucho más fácil de razonar y verificar utilizando herramientas
automatizadas. Además, la necesidad de realizar actualizaciones frecuentes
obliga a los operadores a confiar realmente en la automatización para
monitorear y con fi rmar la seguridad (en lugar de depender de la
verificación manual), y los disuade de asumir que la SDN es muy
consistente (por ejemplo, suponga que los componentes están ejecutando la
misma versión del software); esto ha resultado en sistemas, procesos y
automatización más robustos.
7.7 Investigación en diseño de alta disponibilidad
Nuestras lecciones motivan varias vías de investigación en diseño de alta
disponibilidad, un tema que ha recibido menos atención que el diseño de
alto rendimiento. De hecho, cada lección representa un gran área de
investigación, donde nuestra solución implementada representa un punto
en un gran espacio de diseño que la investigación futura puedeexplorar.
Los ejemplos de direcciones futuras incluyen: formas óptimas de
particionar topologías y dominios de control para contener el radio de
explosión de una falla o formas de diseñar topologías con propiedades de
impacto de falla conocidas; métodos dinámicos para evaluar rápidamente
Cuándo retroceder y qué trá fi co desviar para lograr un retroceso suave y
casi transparente; métodos para
70
razonar estáticamente sobre la coherencia del estado del plano de control y
realizar un seguimiento de la procedencia del estado para garantizar la
coherencia; métodosde medición en banda escalables que permiten una
localización de fallas rápida y precisa y, al mismo tiempo, son resistentes a
fallas y ataques; y técnicas para detectar la apertura en caso de falla de
manera robusta y para conciliar correctamente el estado del plano de
control y de datos en un sistema de apertura en falla tras la recuperación del
plano de control.
Un área grande y poco explorada en el diseño de alta
disponibilidad es el plano de gestión. La investigación futura aquí puede
explorar cómo especificar la "intención" ( es decir, cómo debería verse la
red), cómo configurar y aprovisionar la red según laintención, cómo
recopilar una instantánea de la "verdad básica" de la red [ 12 ] ( es decir,
cómo se ve la red) y cómo reconciliar la intención y la verdad básica
porque, en la práctica, incluso con la configuración y el aprovisionamiento
automatizados basados en laintención, es probable que haya divergencia
entre los dos. Dada la evolución de los grandes proveedores de contenido,
otra área de investigación es la evaluación de riesgos automatizada y
precisa, y los mecanismos para permitir una evolución de la red segura,
pero frecuente, mediante la actualización in situ.
Finalmente, identificamos una serie de desafíos generales.
¿Cómo podemos de fi nir y medir los SLO para una red de una manera que
los servicios o aplicaciones puedan utilizar para su diseño? ¿Cuándo
decimos que una red realmente no está disponible(cuando deja caer
algunos paquetes, cuando su rendimiento cae por debajo de cierto umbral)?
¿Qué técnicas utilizamos para cuantificar las mejoras en la disponibilidad?
8. TRABAJOS RELACIONADOS
Razones genéricas de fallas de sistemas de ingeniería [ 7 , 32 ]
incluyen la heterogeneidad y el impacto de las interacciones y el
acoplamiento entre los componentes del sistema. Nuestro trabajo se
centra en un proveedor de contenido moderno a gran escala;
identificamos clases específicas de razones por las que nuestras redes
fallan, muchas de las cuales pueden atribuirse a la velocidad de evolución
de nuestras redes.
Los fallos de red y su impacto también se han estudiado en sistemas
distribuidos. De la imposibilidad resulta [ 1 ], a técnicas para diseñar sistemas
distribuidos tolerantes a fallas [ 9 ], para experimentar informes sobre fallas
individuales en grandes sistemas distribuidos prácticos [ 28 , 36
], estos estudios arrojan luz sobre fallas reales y sus consecuencias para los
sistemas distribuidos. Bailis y Kingsbury [ 30 ] proporcionan una buena
discusión sobre fallas divulgadas públicamente en sistemas distribuidos
implementados que probablemente fueron causadas por particiones de red.
En contraste con este cuerpo de trabajo, nuestro trabajo se enfoca
en fallas en los planos de control, datos y administración de la red. Si bien
algunas de nuestras fallas son cualitativamente similares a las fallas
observadas en los sistemas distribuidos (cascadas de fallas y fallas de
cerebro dividido), otras, como fallas de la red del plano de control, fallas en
las operaciones del plano de gestión, etc., no surgen ni tienen menor
impacto en los sistemas distribuidos. Del mismo modo, muchas de
nuestras lecciones tienen sus análogos en sistemas distribuidos, p.ej, estrategiasde
respaldo y aislamiento rápido de fallas), pero muchas no lo hacen, p.ej,
apertura de fallas, verificación dinámica de actualizaciones del plano
de control yautomatización del plano de gestión.
Finalmente, la literatura sobre redes ha, durante más de un
década, exploró varias formas de evaluar y cuantificar las fallas en las redes.
Una línea de trabajo inicial exploró las características de falla de enlace en
ISP de mediana a gran escala mediante el examen de la dinámica de los IGP [
33 , 26
, 39 ] y EGP [ 22 ]. No todas las fallas de enlace dan como resultado la pérdida
dela disponibilidad de la red, y nuestro trabajo explora una clase mucho más
amplia de causas raíz de las fallas de disponibilidad, que van desde las
limitaciones de recursos del dispositivo hasta los errores del plano de control
y los errores del plano de gestión. Un trabajo más reciente ha explorado fallas
de enlaces, dispositivos y componentes en empresas [ 37 ], redes académicas [
34
] y centros de datos [ 13 ], utilizando otras fuentes de información, incluidos
errores de syslog, tickets de problemas y quejas de los clientes. Nuestra
fuentede datos, los informes post-mortem, son cualitativamente diferentes de
estas fuentes: nuestros informes están cuidadosamente seleccionados e
incluyen evaluaciones de la causa raíz que generalmente se confirman
mediante una
reproducción cuidadosa en el laboratorio o en entornos de campo
limitados.Por lo tanto, podemos evaluar de manera amplia y más precisa la
causa raíz en diferentes tipos de redes, con diferentes diseños de planos de
control y procesos de planos de gestión. Otro trabajo ha explorado el papel
de la
configuración incorrecta en las fallas de la red [ 29 , 31 ], y métodos para
reducirerrores de configuración errónea con configuraciones de redes de
sombra [ 2 ]; La configuración incorrecta del plano de control es sólo una de
las causas fundamentales que estudiamos.
Finalmente, un trabajo más reciente ha explorado el impacto de las
operaciones del plano de administración en la salud de la red [ 12 ]. Este
trabajo identifica las operaciones del plano de gestión mediante cambiosen
las configuraciones del dispositivo, o mediante cambios en la topología de
la red, y el estado de la red según el número de alertas de dispositivos en la
red, luego aplica pruebas de causalidad estadística para determinar qué
operaciones del plano de gestión pueden afectar el estado. Nuestro trabajo
difiere de muchas formas. Primero, además de nuestro uso de autopsias
curadas por humanos, los MOps que discutimos en este documento son
operaciones completamente documentadas que se revisan y requieren
aprobación, por lo que no necesitamos inferir si una operación de gestión
estaba en vigor. En segundo lugar, la mayoría de nuestras fallas tuvieron un
impacto en la disponibilidad, aunque no está claro hasta qué punto las
medidas de salud de la red reflejan la disponibilidad. Finalmente, nuestro
trabajo intenta unificar las categorías de causa raíz en diferentes tipos de
redes, y también en los planos de datos y control.
9. CONCLUSIONES
Al analizar los informes post-mortem en Google, mostramos quelas fallas
ocurren en todas nuestras redes y en todos los planos.
Muchas fallas ocurren cuando se toca la red, pero las operaciones de
gestión en redes son fundamentales en Google dada su velocidad de
evolución. Estas fallas nos han llevado a adoptar variosprincipios de diseño
de alta disponibilidad y mecanismos asociados que van desde preservar el
plano de datos en caso de falla, contener el radio de falla y diseñar
alternativas para fallas sistémicas, hasta la evaluación automatizada de
riesgos y la automatización del plano de gestión. Nuestra experiencia
sugiere que las redes futuras deben tener en cuenta la evolución y la
actualización continuas como una parte clave de su arquitectura y diseño
de disponibilidad.
Agradecimientos. Agradecemos los excelentes comentariosque hemos
recibido de los revisores.
71
y de nuestro pastor Vyas Sekar. Las discusiones y comentarios de Paulie
Germano, Hossein Lot fi, Subhasree Mandal, Joon Ong, Arjun Singh y
David Wetherall también mejoraron significativamente el artículo. Por
último, este trabajo no hubiera sido posible sin el arduo trabajo de las
operaciones de red de Google, SRE y los equipos de desarrollo que
diseñan, administran y ejecutan nuestra red global y documentan
cuidadosamente y originan cada falla significativa.
Bibliografía
[1] Daniel Abadi. “Compensaciones de coherencia en el diseño
moderno de bases de datos distribuidas: CAP es sólo una partede
la historia”. En: Computadora IEEE ( 2012).
[2] Richard Alimi, Ye Wang y Yang Richard Yang.
“Configuración de la sombra como primitiva de
gestión de red”. En: Proc. ACM SIGCOMM. 2008.
[3] C. Ashton. ¿Cuál es el costo real del tiempo de inactividad de la
red? http: / / www. lectura de la luz. com / centro de datos /
centro de datos infraestructura / cuál es el costo real del tiempo
de inactividad de la red / a / d-id / 710595 . 2014.
[4] B. Schneier. Seguridad en la Nube. https: / / www.
schneier. com / blog / archives / 2006/02 / security_ in_
the.html . 2006.
[5] Betsy Beyer y Niall Richard Murphy. “Ingeniería de
confiabilidad del sitio: cómo Google administra sus clústeres
de producción”. En: O'Reilly, 2016. Cap. 1.
[6] Matt Calder, Xun Fan, Zi Hu, Ethan Katz-Bassett, John
Heidemann y Ramesh Govindan. "Mapeo de la expansión
de la infraestructura de servicio de Google". En:
Proc. de la ACM Internet Measurement Conference
(IMC '13). 2013.
[7] Carlson, JM y Doyle, John. “Tolerancia altamente optimizada:
robustez y diseño en sistemas complejos”. En: Phys. Rev. Lett. 84
(11 2000), págs. 2529–
2532.
[8] Índice de redes visuales de Cisco: la era de los Zettabytes
- Tendencias y análisis. http: / / www. cisco. com / c / en /
us / solutions / colateral / service - provider / visual -
networking- index-vni / VNI_Hyperconnectivity_WP.
html . 2014.
[9] Jeff Dean. Diseños, lecciones y consejos de la construcción de
grandessistemas distribuidos. Conferencia magistral en LADIS 2009.
[10] E. Dubrova. “Diseño tolerante a fallas”. En: Springer,2013. Cap. 2.
Tobias Flach y col. "Reducción de la latencia web: la virtud de
[11] la agresión suave". En: Proc. ACM SIGCOMM.2013.
Aaron Gember-Jacobson, Wenfei Wu, Xiujun Li, AdityaAkella y
Ratul Mahajan. “Análisis del plano de gestión”. En: Actas de ACM
IMC. IMC '15. Tokio, Japón:ACM, 2015, págs. 395–408. ISBN:
[12] 978-1-4503-3848-6.
[13] P. Gill, N. Jain y N. Nagappan. “Comprensión de lasfallas de red en los
centros de datos: medición,
análisis e implicaciones”. En: Proc. ACM SIG- COMM. 2011.
[14] Chuanxiong Guo y col. “Pingmesh: un sistema a gran escala para la
medición y el análisis de la latencia de la red del centro de datos”.
En: Computación SIGCOMM. Comun. Rvdo. 45.5 (agosto de 2015),
[15] págs. 139-152. ISSN:
0146-4833.
R. Hinden. Protocolo de redundancia de enrutador virtual. Grupode
trabajo de ingeniería de Internet, RFC 3768. 2004.
[dieciséis]¿Problemas de Internet hoy? No estás solo. Este es el por qué.
http://www.zdnet.com/article/internet-hiccups-today- no-estas-
solo-aqui-por-que / .
[17] Y. Israelevtsky y A. Tseitlin. El Ejército Simio Net fl ix. http:
/ / techblog.net fl ix.com/2011/07/net fl ix-simian-
army.html . 2011.
[18]
Sushant Jain y col. “B4: Experiencia con una WAN definida por
software implementado globalmente”.En: Actas del ACM
SIGCOMM 2013. SIGCOMM '13.
[19] Hong Kong, China: ACM, 2013, págs. 3-14. ISBN:
978-1-4503-2056-6.
Juniper Networks MX 2020. http://www.juniper.net/ elqNow /
[20]
elqRedir.htm? ref = http: / / www. juniper.net / assets / us / es
[21] / local / pdf / datasheets / 1000417-es.pdf .
K. Krishnan. “Enfrentar lo inesperado”. En: Cola deACM ( 2012).
Alok Kumar y col. “BwE: Asignación de ancho de banda
[22] jerárquica y flexible para computación distribuida WAN”. En: Actasde la [34]
Conferencia de la ACM de 2015 sobre el grupo de
interés especial sobre comunicación de datos.
SIGCOMM '15. Londres, Reino Unido: ACM,2015,
[23]
págs. 1-14. ISBN: 978-1-4503-3542-3.
Craig Labovitz, Abha Ahuja y Farnam Jahanian. “Estudio
[24] experimental de estabilidad de Internet y fallas de redesde área
extensa”. En: Proc. Simposio Internacional sobreComputación
Tolerante a Fallos. 1999.
G. Linden. Haga que los datos sean útiles. http: / / sitios. Google .
[25] com / site / glinden / Inicio / StanfordDataMining.2006-
11-28.ppt . 2006.
M. Canini y D. Venzano y P. Perešíni y
D. Kostić´ y J. Rexford. “Una forma AGRADABLE de probar
aplicaciones OpenFlow”. En: Presentado comoparte del 9º
Simposio de USENIX sobre Diseño e Implementación de Sistemas
en Red (NSDI 12). San José, CA: USENIX, 2012, págs. 127–140.
ISBN:
978-931971-92-8.
M. Kuzniar y P. Peresini y M. Canini y D. Venzano y D.Kostic.
“Una forma SOFT para las pruebas de interoperabilidad de
conmutadores de flujo abierto”.En: Actas de la 8ª Conferencia
Internacional sobre
Experimentos y Tecnologías de Redes Emergentes. CoNEXT[39]
'12. Niza, Francia: ACM, 2012, págs. 265–276. ISBN:
978-1-4503-1775-7.
72
[26] A. Markopoulou, G. Iannaccone, S. Bhattacharyya,
C.-N. Chuah, Y. Ganjali y C. Diot. “Caracterización de fallas en una
red troncal IP operativa”. En: TransaccionesIEEE / ACM en redes (
2008).
[27] I. Minei y J. Lucek. Aplicaciones habilitadas para MPLS: desarrollos
emergentes y nuevas tecnologías. 3er. WileyInc., 2015.
[28] Andrew Montalenti. Kafkapocalypse: un post-mortem sobre
nuestra interrupción del servicio. Publicación del blog técnico de
[29]
Parse.ly. 2015.
N. Feamster y H. Balakrishnan. “Detección de fallas de
configuración de BGP con análisis estático”. En: Avancedel II
Simposio de Diseño e Implementación de Sistemas en Red.
Asociación USENIX. 2005, págs.
43–56.
[30]
P. Bailis y K. Kingsbury. “Una encuesta informal sobre
fallas de comunicaciones en el mundo real”. En: Comunicacionesdel ACM (
[31] 2014).
R. Mahajan y D. Wetherall y T. Anderson. “Comprensiónde la
configuración incorrecta de BGP”. En: Actas de la Conferencia
de 2002 sobre aplicaciones, tecnologías, arquitecturas y
protocolos para las comunicaciones informáticas. SIGCOMM
[32] '02. Pittsburgh, Pensilvania, EE.UU .: ACM, 2002, págs. 3-16.
ISBN: 1-58113-570-
X.
[33]
John Rushby. “Propiedades críticas del sistema: levantamiento y
taxonomía”. En: Ingeniería de confiabilidad y seguridad del
sistema 43.2 (1994), págs. 189–219.
A. Shaikh, C.Isett, A. Greenberg, M. Roughan y
J. Gottlieb. "Un estudio de caso del comportamiento de OSPF en
[35] una gran red empresarial". En: Proc. Taller de medición de
Internet ACM. 2002.
A. Shaikh, C. Isett, A. Greenberg, M. Roughan y J.
[36] Gottlieb. "Líneas de falla de California: comprensión
de las causas y el impacto de las fallas de red". En: Proc. ACM
SIGCOMM. 2010.
Arjun Singh y col. “Jupiter Rising: una década de topologías de
[37]
Clos y control centralizado en la red de centros de datos de
Google”. En: Computación SIGCOMM. Comun. Rvdo. 45.5(agosto
[38] de 2015), págs. 183–197. ISSN: 0146-4833.
Resumen de la interrupción del servicio Amazon EC2 y Amazon
RDS en la región este de EE. UU. http: / / aws. Amazonas. com /
message / 65648 / . Servicios web deAmazon. 2011.
D. Turner, K. Levchenko, JC Mogul, S. Savage y
AC Snoeren. Sobre fallas en redes empresariales administradas.
Tech.reps. HPL-2012-101. Laboratorios HP, 2012.
Amin Vahdat y col. “Escalabilidad y precisión en un emulador
de red a gran escala”. En: SIGOPS Oper. Syst.Rvdo. 36.SI
(diciembre de 2002), págs. 271-284. ISSN: 0163-5980.
D. Watson, F. Jahanian y C. Labovitz. “Experiencias con el
monitoreo de OSPF en una red regional de proveedores de
servicios”. En: Proc. IEEE ICDCS. 2003.
¿POR QUE MI GRUPO DEVERIA ESCOGER ESTRE ARTICULO?
R. Mi grupo debería escoger este artículo porque nos habla de la red que maneja google para conectarnos al
mundo desde como reacciona ante las ampliaciones de red, que hacer si se presentan fallas es por eso que
atreves de este artículo aprendemos como una gran empresa maneja el tema de las redes a nivel mundial y
cómo podemos reaccionar ante fallas que se les presenta a los expertos en google.

73