Gestión eficiente y confiable de clusters a cualquier escala con Tupperware
Hoy en Presentamos Tupperware, nuestro sistema de administración de clústeres que organiza contenedores en millones de servidores que ejecutan casi todos nuestros servicios. Implementamos Tupperware por primera vez en 2011 y desde entonces nuestra infraestructura ha crecido desde hasta el total . Durante todo este tiempo, Tupperware no se quedó quieto y se desarrolló con nosotros. Le mostraremos cómo Tupperware brinda administración de clústeres de primera clase, incluido soporte conveniente para servicios con estado, un panel de control único para todos los centros de datos y la capacidad de distribuir capacidad entre servicios en tiempo real. También compartiremos las lecciones que hemos aprendido a medida que nuestra infraestructura evolucione.
Tupperware realiza diferentes tareas. Los desarrolladores de aplicaciones lo utilizan para entregar y administrar aplicaciones. Empaqueta el código de la aplicación y las dependencias en una imagen y la entrega a los servidores como contenedores. Los contenedores proporcionan aislamiento entre aplicaciones en el mismo servidor para que los desarrolladores se ocupen de la lógica de la aplicación y no tengan que preocuparse por buscar servidores o administrar actualizaciones. Tupperware también monitorea el rendimiento del servidor y, si encuentra una falla, transfiere contenedores desde el servidor problemático.
Los ingenieros de planificación de capacidad utilizan Tupperware para asignar capacidad de servidor a equipos según el presupuesto y las limitaciones. También lo utilizan para mejorar la utilización del servidor. Los operadores de centros de datos recurren a Tupperware para distribuir adecuadamente los contenedores entre los centros de datos y detener o mover contenedores durante el mantenimiento. Gracias a esto, el mantenimiento de servidores, redes y equipos requiere una mínima intervención humana.
arquitectura tupperware
La arquitectura Tupperware PRN es una de las regiones de nuestros centros de datos. La región consta de varios edificios de centros de datos (PRN1 y PRN2) ubicados cerca. Planeamos crear un panel de control que administrará todos los servidores en una región.
Los desarrolladores de aplicaciones ofrecen servicios en forma de trabajos Tupperware. Un trabajo consta de varios contenedores y, por lo general, todos ejecutan el mismo código de aplicación.
Tupperware es responsable de aprovisionar los contenedores y gestionar su ciclo de vida. Consta de varios componentes:
- La interfaz de Tupperware proporciona API para la interfaz de usuario, CLI y otras herramientas de automatización a través de las cuales puedes interactuar con Tupperware. Ocultan toda la estructura interna a los propietarios de trabajos de Tupperware.
- Tupperware Scheduler es un panel de control responsable de gestionar el contenedor y el ciclo de vida del trabajo. Se implementa a nivel regional y global, donde el programador regional administra servidores en una región y el programador global administra servidores de diferentes regiones. El programador se divide en fragmentos y cada fragmento gestiona un conjunto de trabajos.
- El Scheduler Proxy de Tupperware oculta la fragmentación interna y proporciona un panel único y conveniente para los usuarios de Tupperware.
- El asignador de Tupperware asigna contenedores a servidores. El programador maneja la detención, el inicio, la actualización y la conmutación por error de los contenedores. Actualmente, un asignador puede gestionar toda la región sin dividirla en fragmentos. (Tenga en cuenta la diferencia en la terminología. Por ejemplo, el programador en Tupperware corresponde al panel de control en , y el asignador de Tupperware se llama programador en Kubernetes).
- El intermediario de recursos almacena la fuente de verdad para el servidor y los eventos del servicio. Ejecutamos un corredor de recursos para cada centro de datos y almacena toda la información sobre los servidores en ese centro de datos. El intermediario de recursos y el sistema de gestión de capacidad, o sistema de aprovisionamiento de recursos, deciden dinámicamente qué entrega del programador controla qué servidor. El servicio de verificación de estado monitorea los servidores y almacena datos sobre su estado en el intermediario de recursos. Si un servidor tiene problemas o necesita mantenimiento, el intermediario de recursos le dice al asignador y al programador que detengan los contenedores o los muevan a otros servidores.
- El Agente Tupperware es un demonio que se ejecuta en cada servidor y prepara y elimina contenedores. Las aplicaciones se ejecutan dentro de un contenedor, lo que les da más aislamiento y reproducibilidad. En Ya hemos descrito cómo se crean contenedores Tupperware individuales usando imágenes, btrfs, cgroupv2 y systemd.
Características distintivas de Tupperware.
Tupperware es similar en muchos aspectos a otros sistemas de gestión de clústeres como Kubernetes y , pero también hay diferencias:
- Soporte integrado para servicios con estado.
- Un único panel de control para servidores en diferentes centros de datos para automatizar la entrega de contenedores en función de la intención, el desmantelamiento de clusters y el mantenimiento.
- División clara del panel de control para hacer zoom.
- La computación elástica le permite distribuir energía entre servicios en tiempo real.
Desarrollamos estas interesantes funciones para admitir una variedad de aplicaciones con y sin estado en una enorme flota global de servidores compartidos.
Soporte integrado para servicios con estado.
Tupperware opera una variedad de servicios críticos con estado que almacenan datos persistentes de productos para Facebook, Instagram, Messenger y WhatsApp. Podrían ser grandes almacenes de pares clave-valor (p. ej. ) y monitorear repositorios de datos (por ejemplo, и ). Mantener servicios con estado no es fácil, porque el sistema debe garantizar que el suministro de contenedores pueda soportar interrupciones a gran escala, incluidos cortes de red o cortes de energía. Y aunque las técnicas convencionales, como la distribución de contenedores entre dominios de falla, funcionan bien para servicios sin estado, los servicios con estado necesitan soporte adicional.
Por ejemplo, si una falla del servidor hace que una réplica de la base de datos no esté disponible, ¿debería habilitar el mantenimiento automático que actualizará los núcleos en 50 servidores de un grupo de 10 50? Depende de la situación. Si uno de estos 2 servidores tiene otra réplica de la misma base de datos, es mejor esperar y no perder XNUMX réplicas a la vez. Para tomar decisiones dinámicas sobre el mantenimiento y el rendimiento del sistema, necesitamos información sobre la replicación de datos internos y la lógica de ubicación de cada servicio con estado.
La interfaz TaskControl permite que los servicios con estado influyan en las decisiones que afectan la disponibilidad de los datos. Utilizando esta interfaz, el programador notifica a las aplicaciones externas sobre las operaciones del contenedor (reinicio, actualización, migración, mantenimiento). Un servicio con estado implementa un controlador que le indica a Tupperware cuándo es seguro realizar cada operación, y estas operaciones pueden intercambiarse o retrasarse temporalmente. En el ejemplo anterior, el controlador de la base de datos podría decirle a Tupperware que actualice 49 de los 50 servidores, pero que deje un servidor específico (X) solo por ahora. Como resultado, si pasa el período de actualización del kernel y la base de datos aún no puede restaurar la réplica problemática, Tupperware seguirá actualizando el servidor X.
Muchos servicios con estado en Tupperware usan TaskControl no directamente, sino a través de ShardManager, una plataforma común para crear servicios con estado en Facebook. Con Tupperware, los desarrolladores pueden especificar su intención sobre cómo se deben distribuir exactamente los contenedores en los centros de datos. Con ShardManager, los desarrolladores especifican su intención sobre cómo se deben distribuir los fragmentos de datos entre los contenedores. ShardManager es consciente de la ubicación de datos y la replicación de sus aplicaciones y se comunica con Tupperware a través de la interfaz TaskControl para programar operaciones de contenedores sin participación directa de las aplicaciones. Esta integración simplifica enormemente la gestión de servicios con estado, pero TaskControl es capaz de hacer más. Por ejemplo, nuestra extensa capa web no tiene estado y utiliza TaskControl para ajustar dinámicamente la tasa de actualizaciones de los contenedores. Eventualmente por día sin comprometer la disponibilidad.
Gestión de servidores en centros de datos.
Cuando Tupperware se lanzó por primera vez en 2011, cada clúster de servidores estaba administrado por un programador independiente. En aquel entonces, un clúster de Facebook era un grupo de bastidores de servidores conectados a un conmutador de red, y el centro de datos albergaba varios clústeres. El programador solo podía administrar servidores en un clúster, lo que significa que el trabajo no podía distribuirse entre varios clústeres. Nuestra infraestructura creció, cada vez descartamos más clusters. Dado que Tupperware no podía trasladar el trabajo del clúster fuera de servicio a otros clústeres sin realizar cambios, requirió mucho esfuerzo y una cuidadosa coordinación entre los desarrolladores de aplicaciones y los operadores del centro de datos. Este proceso resultó en un desperdicio de recursos cuando los servidores estuvieron inactivos durante meses debido a los procedimientos de desmantelamiento.
Creamos un intermediario de recursos para resolver el problema del desmantelamiento del clúster y coordinar otros tipos de tareas de mantenimiento. El intermediario de recursos realiza un seguimiento de toda la información física asociada con un servidor y decide dinámicamente qué programador controla cada servidor. Vincular dinámicamente servidores a programadores permite al programador administrar servidores en diferentes centros de datos. Dado que un trabajo de Tupperware ya no se limita a un solo clúster, los usuarios de Tupperware pueden especificar cómo se deben distribuir los contenedores entre los dominios de falla. Por ejemplo, un desarrollador puede declarar su intención (por ejemplo: "ejecutar mi trabajo en 2 dominios de error en la región PRN") sin especificar zonas de disponibilidad específicas. El propio Tupperware encontrará servidores adecuados para implementar esta intención, incluso si el clúster o servicio está fuera de servicio.
Escalable para soportar todo el sistema global
Históricamente, nuestra infraestructura se ha dividido en cientos de grupos de servidores dedicados para equipos individuales. Debido a la fragmentación y la falta de estándares, teníamos altos costos operativos y los servidores inactivos eran más difíciles de volver a usar. En la conferencia del año pasado presentamos , que debería unir nuestra infraestructura en un gran parque de servidores únicos. Pero un parque de servidores único tiene sus propias dificultades. Debe cumplir ciertos requisitos:
- Escalabilidad. Nuestra infraestructura creció a medida que agregamos centros de datos en cada región. Los servidores se han vuelto más pequeños y más eficientes energéticamente, por lo que hay muchos más en cada región. Como resultado, un único programador por región no puede manejar la cantidad de contenedores que se pueden ejecutar en cientos de miles de servidores en cada región.
- Confiabilidad. Incluso si el programador se puede ampliar tanto, el gran alcance del programador significa que existe un mayor riesgo de errores y una región entera de contenedores podría volverse inmanejable.
- Tolerancia a fallos. En caso de una falla importante en la infraestructura (por ejemplo, los servidores que ejecutan el programador fallan debido a una falla en la red o un corte de energía), las consecuencias negativas deberían afectar solo a una parte de los servidores de la región.
- Facilidad de uso. Puede parecer que necesita ejecutar varios programadores independientes para una región. Pero desde una perspectiva de conveniencia, un único punto de entrada al fondo compartido de una región facilita la gestión de la capacidad y los empleos.
Dividimos el programador en fragmentos para resolver los problemas de mantener un grupo compartido grande. Cada fragmento del programador administra su propio conjunto de trabajos en la región y esto reduce el riesgo asociado con el programador. A medida que crece el grupo compartido, podemos agregar más fragmentos del programador. Para los usuarios de Tupperware, los shards y los proxies del programador parecen un solo panel de control. No tienen que trabajar con un montón de fragmentos que organizan tareas. Los fragmentos del programador son fundamentalmente diferentes de los programadores de clúster que usamos antes, donde el panel de control se dividía sin dividir estáticamente el grupo compartido de servidores según la topología de la red.
Mejore la eficiencia del uso con Elastic Computing
Cuanto mayor sea nuestra infraestructura, más importante será utilizar nuestros servidores de manera eficiente para optimizar los costos de infraestructura y reducir la carga. Hay dos formas de aumentar la eficiencia del uso del servidor:
- Computación elástica: reduzca los servicios en línea durante las horas tranquilas y use servidores liberados para cargas de trabajo fuera de línea, como aprendizaje automático y trabajos de MapReduce.
- Sobrecarga: coloque los servicios en línea y las cargas de trabajo por lotes en los mismos servidores para que las cargas de trabajo por lotes se ejecuten con baja prioridad.
El cuello de botella en nuestros centros de datos es . Por lo tanto, preferimos servidores pequeños y energéticamente eficientes que, en conjunto, proporcionen más potencia de procesamiento. Desafortunadamente, en servidores pequeños con poca CPU y memoria, la sobrecarga es menos efectiva. Por supuesto, podemos colocar varios contenedores de servicios pequeños en un servidor pequeño de bajo consumo que consuma pocos recursos de procesador y memoria, pero los servicios grandes tendrán un rendimiento bajo en esta situación. Por lo tanto, recomendamos a los desarrolladores de nuestros grandes servicios que los optimicen para que utilicen todos los servidores.
Básicamente, mejoramos la eficiencia del uso mediante la computación elástica. Muchos de nuestros servicios principales, como la sección de noticias, la función de mensajería y el nivel web front-end, varían según la hora del día. Reducimos intencionalmente los servicios en línea durante las horas de tranquilidad y utilizamos servidores liberados para cargas de trabajo fuera de línea, como aprendizaje automático y trabajos de MapReduce.
Sabemos por experiencia que es mejor aprovisionar servidores completos como unidades de capacidad elástica porque los servicios grandes son a la vez los principales donantes y consumidores de capacidad elástica, y están optimizados para utilizar servidores completos. Cuando el servidor sale del servicio en línea durante las horas de tranquilidad, el agente de recursos alquila el servidor al programador para ejecutar cargas de trabajo sin conexión en él. Si el servicio en línea experimenta un pico de carga, el intermediario de recursos recupera rápidamente el servidor prestado y, junto con el programador, lo devuelve al servicio en línea.
Lecciones aprendidas y planes para el futuro
Durante los últimos 8 años, hemos estado desarrollando Tupperware para mantenernos al día con el rápido crecimiento de Facebook. Compartimos lo que hemos aprendido y esperamos que ayude a otros a gestionar infraestructuras en rápido crecimiento:
- Configure una conexión flexible entre el panel de control y los servidores que gestiona. Esta flexibilidad permite que el panel de control administre servidores en diferentes centros de datos, ayuda a automatizar el desmantelamiento y el mantenimiento de los clústeres y permite la asignación dinámica de capacidad mediante computación elástica.
- Con un único panel de control en la región, resulta más conveniente trabajar con tareas y más fácil administrar una gran flota de servidores compartidos. Tenga en cuenta que el panel de control mantiene un único punto de entrada, incluso si su estructura interna está separada por razones de escala o tolerancia a fallas.
- Utilizando un modelo de complemento, el panel de control puede notificar a aplicaciones externas sobre las próximas operaciones de contenedores. Además, los servicios con estado pueden utilizar la interfaz del complemento para personalizar la gestión de contenedores. Con este modelo de complemento, el panel de control proporciona simplicidad al mismo tiempo que brinda servicio eficiente a muchos servicios con estado diferentes.
- Creemos que la informática elástica, en la que retiramos servidores completos de los servicios donantes para trabajos por lotes, aprendizaje automático y otros servicios no urgentes, es la forma óptima de mejorar la eficiencia de los servidores pequeños y energéticamente eficientes.
Recién estamos comenzando a implementar . Actualmente, alrededor del 20% de nuestros servidores se encuentran en un grupo compartido. Para lograr el 100%, es necesario abordar muchos problemas, incluido el mantenimiento de un grupo de almacenamiento compartido, la automatización del mantenimiento, la gestión de los requisitos entre inquilinos, la mejora de la utilización del servidor y la mejora del soporte para cargas de trabajo de aprendizaje automático. Estamos ansiosos por asumir estos desafíos y compartir nuestros éxitos.
Fuente: habr.com