Libro "Ingeniería de confiabilidad del sitio. Fiabilidad y fiabilidad como en Google »

Durante casi 20 años, Google ha estado proporcionando sistemas inimaginablemente complejos y a gran escala que son sensibles a las solicitudes de los usuarios. El motor de búsqueda de Google encuentra la respuesta a cualquier pregunta en una fracción de segundo, los mapas de Google con la mayor precisión reflejan el paisaje terrestre, y el correo de Google está disponible en modo 365/24/7 y, en esencia, se ha convertido en el primer almacenamiento en la nube pública. ¿Son estos sistemas perfectos? No, también fallan, se rompen y se vuelven obsoletos, como cualquier equipo. Simplemente no lo notamos. La cuestión es que, durante más de diez años, Google ha estado desarrollando la tecnología única de ingeniería de confiabilidad del sitio, que garantiza el funcionamiento ininterrumpido y el desarrollo progresivo de sistemas de software de cualquier complejidad. Este libro es un depósito de experiencia acumulada por Google a lo largo de muchos años, el trabajo colectivo de muchos especialistas destacados y un recurso indispensable para cualquier ingeniero que desee desarrollar y mantener cualquier producto con la más alta calidad y de la manera más eficiente.

SRE de Google en términos de SRE

Los centros de datos de Google (centros de datos) son significativamente diferentes de los centros de datos tradicionales y las "granjas" de servidores pequeños. Estas diferencias introducen problemas adicionales y oportunidades adicionales. Este capítulo analiza los desafíos y oportunidades específicos de los centros de datos de Google e introduce la terminología que se utilizará en todo el libro.

Equipo

La mayoría de los recursos informáticos de Google se encuentran en centros de datos diseñados por la empresa, que tienen su propio sistema de suministro de energía, sistema de refrigeración, red interna y equipo informático [Barroso et al., 2013]. A diferencia de los centros de datos típicos proporcionados por los proveedores a sus clientes, todos los centros de datos de Google están equipados con lo mismo1. Para evitar confusiones entre el hardware del servidor y el software del servidor, en este libro usamos la siguiente terminología:

• máquina (computadora) : una unidad de equipo (o, posiblemente, una máquina virtual);
• servidor : una unidad de software que implementa un servicio.

Cualquier servidor puede iniciarse en máquinas, por lo tanto, no asignamos computadoras específicas para programas de servidor específicos. Por ejemplo, no tenemos una máquina específica en la que se esté ejecutando el servidor de correo. En cambio, los recursos son asignados por nuestro sistema de gestión de clúster Borg.

Entendemos que tal uso del término "servidor" no es estándar. Es más habitual designar dos conceptos a la vez: un programa que sirve conexiones de red y, al mismo tiempo, una máquina que ejecuta dichos programas, pero cuando hablamos de la potencia informática de Google, la diferencia entre ambos es significativa. Tan pronto como se acostumbre a nuestra interpretación de la palabra "servidor", le resultará más claro por qué es importante utilizar una terminología tan especializada no solo directamente en Google, sino a lo largo de este libro.

En la fig. 2.1 demostró la configuración del centro de datos de Google.

• Se colocan docenas de autos en bastidores.
• Los bastidores se colocan en filas.
• Una o más filas forman un grupo.
• Por lo general, en la construcción de un centro de datos (DPC) o centro de datos, se ubican varios grupos.
• Varios edificios de centros de datos que están cerca uno del otro conforman el campus.

Dentro de cada centro de datos, todas las máquinas deberían poder comunicarse efectivamente entre sí, por lo que creamos un conmutador virtual muy rápido (conmutador) con decenas de miles de puertos. Esto fue posible conectando cientos de conmutadores desarrollados por Google en una "fábrica" ​​basada en la topología de la red Clos [Clos, 1953], llamada Júpiter [Singh et al., 2015]. En su configuración máxima, Júpiter admite un rendimiento de 1.3 Pb / s entre servidores.

Los centros de datos se conectan entre sí mediante nuestra red troncal B4 global [Jain et al., 2013]. B4 tiene una arquitectura de red configurable por software y utiliza el protocolo de comunicación abierta OpenFlow. B4 proporciona un ancho de banda amplio a un número limitado de sistemas y utiliza un control de ancho de canal flexible para maximizar su valor promedio [Kumar et al., 2015].

Software del sistema que "organiza" el equipo

El software que proporciona la gestión y administración de nuestros equipos debe ser capaz de manejar grandes sistemas. Las fallas de hardware son uno de los principales problemas resueltos con la ayuda del software. Dada la gran cantidad de componentes de hardware en un clúster, suceden con bastante frecuencia. En cada grupo, miles de máquinas suelen fallar en un año y fallan miles de discos duros. Si multiplica este número por el número de grupos que operan en todo el mundo, el resultado es asombroso. Por lo tanto, queremos aislar a los usuarios de tales problemas, y los equipos involucrados en nuestros servicios tampoco quieren ser distraídos por problemas de hardware. Cada campus del centro de datos tiene equipos que son responsables de apoyar el equipo y la infraestructura del centro de datos.

Gestión de la máquina

Borg (Figura 2.2) es un sistema de gestión de clúster distribuido [Verma et al., 2015], similar a Apache Mesos. Borg gestiona trabajos a nivel de clúster.
Borg es responsable de lanzar trabajos de usuario. Estas tareas pueden ser servicios que se ejecutan constantemente o procesos por lotes como MapReduce [Dean y Ghemawat, 2004]. Pueden consistir en varias (a veces miles) de tareas (tareas) idénticas, tanto por razones de confiabilidad como porque un proceso, por regla general, no puede procesar todo el tráfico del clúster. Cuando Borg comienza la tarea, encuentra las máquinas para realizar sus tareas y les ordena que inicien el programa del servidor. Borg luego monitorea el estado de estas tareas. Si la tarea no funciona correctamente, se destruye y se reinicia, posiblemente en otra máquina.

Dado que las tareas se distribuyen libremente entre las máquinas, no podemos usar direcciones IP y números de puerto para acceder a ellas. Este problema se resuelve mediante un nivel adicional de abstracción: al iniciar una tarea, Borg asigna un nombre para la tarea y un número (índice) para cada tarea utilizando el servicio de nombres Borg (BNS). En lugar de usar la dirección IP y el número de puerto, otros procesos se asocian con las tareas de Borg por su nombre BNS, que luego convierte el BNS en dirección IP y número de puerto. Por ejemplo, la ruta BNS puede ser una cadena como / bns / <cluster> / <user> / <task_name> / <task_number>, que luego se traduce (es habitual decir "permitido" en las redes) en el formato <dirección IP>: <port> .

Borg también es responsable de asignar recursos para las tareas. Cada tarea debe indicar qué recursos se requieren para completarla (por ejemplo, tres núcleos de procesador, 2 GB de RAM). Utilizando la lista de requisitos para todas las tareas, Borg puede distribuir de manera óptima las tareas entre las máquinas, teniendo en cuenta también las consideraciones de tolerancia a fallas (por ejemplo, Borg no iniciará todas las tareas de una tarea en el mismo rack, ya que el cambio de este rack será un punto crítico en caso de falla) tareas).

Si una tarea intenta obtener más recursos de los solicitados, Borg la destruye y luego se reinicia (ya que generalmente es preferible tener una tarea que a veces se bloquea y se reinicia que no se reinicia en absoluto).

Almacenamiento

Para un acceso más rápido a los datos, las tareas pueden usar el disco local de las máquinas, pero tenemos varias opciones para organizar el almacenamiento persistente en el clúster (e incluso los datos almacenados localmente eventualmente se moverán al almacenamiento del clúster). Se pueden comparar con Luster y el Sistema de archivos distribuidos de Hadoop (HDFS): sistemas de archivos en clúster con una implementación de código abierto.

El almacenamiento proporciona a los usuarios la capacidad de acceder de manera fácil y confiable a los datos disponibles para el clúster. Como se muestra en la fig. 2.3, el repositorio tiene varias capas.


1. La capa más baja se llama D (desde el disco, aunque el nivel D usa tanto discos duros tradicionales como unidades flash). D es un servidor de archivos que se ejecuta en prácticamente todas las máquinas de clúster. Sin embargo, los usuarios que desean acceder a sus datos no querrán recordar en qué máquina están almacenados, por lo que la siguiente capa está conectada aquí.

2. Sobre la capa D está la capa Coloso, que crea un sistema de archivos en el clúster que ofrece la semántica habitual del sistema de archivos, así como la replicación y el cifrado. Colossus es el sucesor de GFS, el Sistema de archivos de Google (Ghemawat et al., 2003).

3. A continuación, hay varios servicios similares a bases de datos creados por encima del nivel Coloso.

• Bigtable [Chang et al., 2006] es un sistema de base de datos no relacional (NoSQL) capaz de trabajar con bases de datos del tamaño de petabytes. Bigtable es una base de datos ordenada, distribuida, tolerante a fallas, multidimensional, ordenada que está indexada por filas, columnas y claves de sello de tiempo; cada valor de la base de datos es una matriz arbitraria no interpretada de bytes. Bigtable también admite la replicación entre centros de datos.
• Spanner [Corbett et al., 2012] ofrece una interfaz similar a SQL para usuarios que requieren integridad y consistencia de datos al acceder desde cualquier parte del mundo.
• Varios otros sistemas de bases de datos están disponibles, como Blobstore. Todos tienen sus propias fortalezas y debilidades (ver capítulo 26).

Red

Google Networking se gestiona de varias maneras. Como se mencionó anteriormente, utilizamos una red configurable por software basada en OpenFlow. En lugar de enrutadores inteligentes, utilizamos conmutadores no tan caros en combinación con un controlador central (duplicado), que calcula previamente la mejor ruta en la red. Esto le permite utilizar un equipo de conmutación más simple, lo que lo libera de la búsqueda de rutas que lleva mucho tiempo.

El ancho de banda de la red debe asignarse adecuadamente. Como Borg limita los recursos informáticos que una tarea puede usar, Bandwidth Enforcer (BwE) gestiona el ancho de banda disponible para maximizar el rendimiento promedio. La optimización del ancho de banda no solo está relacionada con el costo: la gestión centralizada del tráfico resuelve una serie de problemas que son extremadamente difíciles de resolver mediante una combinación de enrutamiento distribuido y gestión convencional del tráfico (Kumar, 2015).

Algunos servicios tienen trabajos que se ejecutan en varios grupos ubicados en diferentes partes del mundo. Para reducir el tiempo de retraso de los sistemas distribuidos globalmente, nos gustaría dirigir a los usuarios al centro de datos más cercano que tenga la capacidad adecuada para esto. Nuestro Global Software Load Balancer (GSLB) realiza el equilibrio de carga en tres niveles:

• el equilibrio de carga geográfica para consultas DNS (por ejemplo, en www.google.com ), se describe en el capítulo 19;
• equilibrio de carga a nivel de servicios de usuario (por ejemplo, YouTube o Google Maps);
• equilibrio de carga en el nivel de Llamada a procedimiento remoto (RPC), descrito en el Capítulo 20.

Los propietarios de servicios especifican nombres simbólicos para ellos, una lista de direcciones BNS del servidor y el rendimiento disponible en cada sitio (generalmente se mide en consultas por segundo, consultas por segundo, QPS). Posteriormente, el GSLB enruta el tráfico a las direcciones BNS especificadas.

Otro software del sistema

Hay otros componentes importantes para el software del centro de datos.

Servicio de bloqueo

El Servicio Chubby Lock [Burrows, 2006] proporciona una API similar al sistema de archivos para servir bloqueos. Chubby maneja bloqueos en todos los centros de datos. Utiliza el protocolo Paxos para acceder asíncronamente al Consenso (ver capítulo 23).

Chubby también juega un papel importante en la elección de un asistente. Si para algún servicio se proporcionan cinco réplicas de una tarea con el fin de aumentar la confiabilidad, pero en un momento particular solo una de ellas hace el trabajo real, entonces Chubby se usa para seleccionar esta réplica.
Chubby es ideal para datos que requieren confiabilidad de almacenamiento. Por esta razón, BNS usa Chubby para almacenar la proporción de rutas BNS a la dirección IP: pares de puertos.

Monitoreo y Alertas

Queremos asegurarnos de que todos los servicios funcionen correctamente. Por lo tanto, estamos lanzando muchas instancias del programa de monitoreo Borgmon (ver capítulo 10). Borgmon recibe regularmente valores de referencia de los servicios supervisados. Estos datos pueden usarse inmediatamente para notificación o almacenarse para su posterior procesamiento y análisis, por ejemplo, para construir gráficos. Tal monitoreo puede ser usado para propósitos tales como:

• configurar alertas para problemas urgentes;
• comparación de comportamiento: la actualización del software aceleró el servidor;
• evaluación de la naturaleza de los cambios en el consumo de recursos a lo largo del tiempo, lo cual es necesario para la planificación de la capacidad.

Nuestra infraestructura de software

La arquitectura de nuestro software está diseñada para que sea posible utilizar los recursos de hardware del sistema de manera más eficiente. Nuestro código completo es multiproceso, por lo que una tarea puede usar fácilmente varios núcleos. Para admitir paneles, monitoreo y depuración, cada servidor incluye una implementación de servidor HTTP como interfaz a través de la cual se proporciona información de diagnóstico y estadísticas para una tarea específica.

Todos los servicios de Google "se comunican" utilizando la infraestructura de llamada a procedimiento remoto (RPC) llamada Stubby. Hay una versión de código abierto, se llama gRPC (ver grpc.io ). A menudo, se realiza una llamada RPC incluso para rutinas en el programa local. Esto le permite reorientar el programa a las llamadas de otro servidor para lograr una mayor modularidad o a medida que crece el código del servidor original. GSLB puede realizar el equilibrio de carga RPC de la misma manera que para las interfaces de servicios externos.

El servidor recibe solicitudes RPC desde el front end y envía el RPC al backend. Usando términos tradicionales, la interfaz se llama cliente y el servidor se llama servidor.
Los datos se transfieren hacia y desde RPC utilizando el protocolo de serialización, los llamados buffers de protocolo o, brevemente, protobufs. Este protocolo es similar al Thrift de Apache y tiene varias ventajas sobre XML cuando se trata de serializar datos estructurados: es más simple, tres a diez veces más compacto, 20 a 100 veces más rápido y más único.

Nuestro entorno de desarrollo

La velocidad del desarrollo del producto es muy importante para Google, por lo que creamos un entorno especial que aprovecha al máximo nuestra infraestructura [Morgenthaler et al., 2012].

Con la excepción de algunos grupos cuyos productos son de código abierto y, por lo tanto, usan sus propios repositorios separados (por ejemplo, Android y Chrome), los ingenieros de software de Google trabajan en un repositorio común [Potvin, Levenberg, 2016]. Este enfoque tiene varias aplicaciones prácticas que son importantes para nuestro proceso de producción.

• Si un ingeniero encuentra un problema en un componente fuera de su proyecto, puede solucionar el problema, enviar los cambios propuestos ("lista de cambios" - lista de cambios, CL) al propietario para su consideración y luego implementar los cambios realizados en la rama principal del programa.
• Los cambios en el código fuente en el propio proyecto de un ingeniero requieren consideración: realizar una auditoría (revisión). Todo el software pasa esta etapa antes de la adopción.

Cuando se ensambla el software, la solicitud de ensamblado se envía a servidores de centros de datos especializados. Incluso construir proyectos grandes es rápido porque puede usar múltiples servidores para compilación paralela. Dicha infraestructura también se utiliza para pruebas continuas. Cada vez que aparece una nueva lista de cambios (CL), se ejecutan pruebas de todo el software que puede verse afectado directa o indirectamente por esos cambios. Si el marco detecta que los cambios interrumpieron la operación de otras partes del sistema, notifica al propietario de estos cambios. Algunos proyectos utilizan el sistema push-on-green ("envío con éxito"), según el cual la nueva versión se envía automáticamente a operación comercial después de pasar las pruebas.

Shakespeare: ejemplo de servicio

Para demostrar cómo Google desarrolla un servicio en un entorno industrial, considere un ejemplo de un servicio hipotético que interactúa con las tecnologías de Google. Supongamos que queremos ofrecer un servicio que le permita determinar en qué obras de Shakespeare se produce la palabra que ha mencionado.

Podemos dividir el sistema en dos partes.

• Un componente de procesamiento por lotes que lee todos los textos de Shakespeare, crea un índice y lo escribe en Bigtable. Esta tarea (más precisamente, la tarea) se realiza una vez o, posiblemente, ocasionalmente (¡después de todo, puede aparecer algún texto nuevo de Shakespeare!).
• Una aplicación front-end que procesa las solicitudes de los usuarios finales. Esta tarea siempre se está ejecutando, porque en cualquier momento, un usuario de cualquier zona horaria puede querer buscar en los libros de Shakespeare.

El componente de procesamiento por lotes será el servicio MapReduce, cuyo trabajo se divide en tres fases.

1. En la fase de mapeo, los textos de Shakespeare se leen y se dividen en palabras separadas. Esta parte del trabajo se completará más rápido si se inician varios procesos de trabajo (tareas) en paralelo.

2. En la fase Aleatorio, las entradas se ordenan por palabra.

3. En la fase Reducir, se crean tuplas del formulario (word, list_products).

Cada tupla se escribe como una cadena en Bigtable, la clave es la palabra.

Solicitar ciclo de vida

En la fig. 2.4 muestra cómo se atiende la solicitud del usuario. Primero, el usuario hace clic en el enlace shakespeare.google.com en el navegador. Para obtener la dirección IP adecuada, el dispositivo del usuario traduce ("resuelve") la dirección utilizando el servidor DNS (1). La consulta DNS finalmente termina en el servidor DNS de Google, que interactúa con el GSLB. Rastreando la carga de tráfico de todos los servidores front-end por región, GSLB elige qué dirección IP de qué servidor devolverá al usuario.

El navegador se conecta al servidor HTTP en la dirección especificada. Este servidor (se llama Google Frontend o GFE) es un servidor proxy "inverso" ubicado en el otro extremo de la conexión TCP del cliente (2). GFE busca el servicio requerido (por ejemplo, puede ser un servicio de búsqueda, mapas o, en nuestro caso, el servicio de Shakespeare). Accediendo repetidamente al GSLB, el servidor encuentra un servidor front-end Shakespeare disponible y accede a él a través de una llamada a procedimiento remoto (RPC), transmitiendo una solicitud HTTP recibida del usuario (3).

El servidor de Shakespeare analiza la solicitud HTTP y crea un "búfer de protocolo" (protobuf) que contiene las palabras que se encuentran. Ahora, el servidor front-end de Shakespeare debe contactar al servidor back-end de Shakespeare: el primero se pone en contacto con el GSLB para obtener la dirección BNS de una instancia adecuada y descargada del segundo (4). A continuación, el servidor back-end de Shakespeare se pone en contacto con el servidor Bigtable para recibir los datos solicitados (5).

El resultado se escribe en el protocolo de respuesta y se devuelve al servidor de back-end de Shakespeare. El backend pasa el protocolo con el resultado del servicio al servidor front-end de Shakespeare, que crea un documento HTML y lo devuelve como respuesta al usuario.


Toda esta cadena de eventos se ejecuta en un abrir y cerrar de ojos, ¡en solo unos cientos de milisegundos! Como hay muchos componentes involucrados, hay muchos lugares donde puede ocurrir un error potencial; en particular, una falla en el GSLB puede desorganizar todo el trabajo y llevar al colapso.Sin embargo, la política de control estricto, pruebas exhaustivas e implementación segura de nuevos programas de Google, además de nuestros métodos proactivos de recuperación de errores (como la eliminación gradual de las funciones), nos permite crear servicios confiables que satisfacen las expectativas de nuestros usuarios. Al final, las personas visitan regularmente www.google.com para verificar si tienen una conexión a Internet.

Organización de tareas y datos.

Probar la carga mostró que nuestro servidor back-end puede procesar aproximadamente 100 solicitudes por segundo (QPS). Las pruebas de campo con un número limitado de usuarios han demostrado que la carga máxima puede alcanzar aproximadamente 3470 QPS, por lo que debemos crear al menos 35 tareas. Sin embargo, las siguientes consideraciones dicen que necesitamos al menos 37 tareas, o N + 2.

• Durante la actualización, una tarea no estará disponible temporalmente, por lo que 36 tareas permanecerán activas.
• Durante la actualización, puede ocurrir una falla de hardware, lo que resulta en solo 35 tareas restantes, exactamente tantas como sea necesario para mantener la carga máxima.

Un estudio más detallado del tráfico de usuarios revela la distribución geográfica de la carga máxima: se generan 1430 QPS de América del Norte, 290 de América del Sur, 1400 de Europa y 350 de Asia y Australia. En lugar de colocar todos los servidores de back-end en un solo lugar, los distribuimos por región: en Estados Unidos, Sudamérica, Europa y Asia. Dado el principio de N + 2 en cada región, tenemos 17 tareas en los Estados Unidos, 16 en Europa y seis en Asia. Sin embargo, en América del Sur, decidimos utilizar cuatro tareas (en lugar de cinco) para reducir los costos, de N + 2 a N + 1. En este caso, estamos listos para correr un pequeño riesgo de un mayor tiempo de retraso y reducir el costo del equipo: permitir GSLB Al recargar el centro de datos de América del Sur, redirigir el tráfico de un continente a otro, podemos ahorrar el 20% de los recursos,eso se gastaría en equipo. En regiones más grandes, para mayor estabilidad, distribuimos tareas entre 2 y 3 grupos.

Dado que los servidores de fondo deben comunicarse con el almacén de datos de Bigtable, también debemos considerar estratégicamente este almacenamiento. Si el servidor de back-end en Asia se comunica con Bigtable, ubicado en los EE. UU., Esto conducirá a un aumento significativo en la latencia, por lo que duplicaremos Bigtable en cada región. Esto nos brinda mayor estabilidad en caso de que el servidor Bigtable falle y también reduce la latencia del acceso a datos. Aunque Bigtable no garantiza una correspondencia estricta de los datos entre las instancias en un momento dado, la duplicación no se convierte en un problema grave, ya que no necesitamos actualizar los contenidos del repositorio con demasiada frecuencia.

Entonces, en este capítulo te has familiarizado con muchos conceptos y términos. Aunque no es necesario memorizarlos todos, pueden ser útiles para explorar muchos otros sistemas, que discutiremos más adelante.

»Se puede encontrar más información sobre el libro en el sitio web del editor
» Contenidos
» Extracto

Cupón de 20% de descuento para Habrozavitel - Ingeniería de confiabilidad del sitio