¡Saludos a la comunidad de Habr! Recientemente escribí sobre nuestra placa de clúster de primera versión []. Y hoy quiero contarles cómo trabajamos en la versión memoria RAM.
Nos apasionan los mini servidores que se pueden usar tanto para desarrollo local como para alojamiento local. A diferencia de las computadoras de escritorio o portátiles, nuestros servidores están diseñados para funcionar 24/7 y se pueden conectar rápidamente en federación; por ejemplo, teníamos 4 procesadores en el clúster y en 5 minutos pasamos a 16 procesadores (sin equipo de red adicional), todo esto en un formato compacto, silencioso y eficiente energéticamente.
La arquitectura de nuestros servidores se basa en el principio de clúster, es decir, fabricamos placas de clúster que conectan varios módulos de cálculo (procesadores) a través de una red Ethernet en la placa. Por simplificación, hasta ahora no hemos fabricado nuestros propios módulos de cálculo, sino que utilizamos Raspberry Pi Compute Modules, y teníamos muchas esperanzas en el nuevo módulo CM4. Sin embargo, todo se salió de nuestros planes con su nuevo formato y creo que muchos están decepcionados.
A continuación, cómo pasamos de V1 a V2 y cómo tuvimos que adaptarnos al nuevo formato de Raspberry Pi CM4.
Así que, después de crear un clúster de 7 nodos, las preguntas son: ¿qué sigue? ¿Cómo aumentar el valor del producto? ¿8, 10 o 16 nodos? ¿Qué fabricantes de módulos? Al pensar en el producto en su conjunto, nos dimos cuenta de que lo fundamental aquí no es el número de nodos o quién es el fabricante, sino la esencia misma de los clústeres como bloque de construcción. Hay que buscar el bloque de construcción mínimo, que
Primera, será un clúster y al mismo tiempo tener la capacidad de conectar discos y placas de expansión. El bloque de clúster debe ser un nodo base autosuficiente y con amplias posibilidades de expansión.
Segunda, de modo que los bloques de clúster mínimos puedan conectarse entre sí formando clústeres de mayor tamaño y que esto sea eficiente en términos de presupuesto y velocidad de escalamiento. La velocidad de escalamiento debe ser superior a la conexión de computadoras comunes en red y mucho más económica que el equipo de servidor.
Tercero, los bloques de clúster mínimos deben ser lo suficientemente compactos, móviles, energéticamente eficientes, rentables y no exigentes en cuanto a las condiciones de operación. Esta es una de las diferencias clave respecto a los racks de servidores y todo lo relacionado con ellos.
Comenzamos definiendo la cantidad de nodos.
Cantidad de nodos
Con simples razonamientos lógicos entendimos que 4 nodos es la mejor opción para un bloque de clúster mínimo. 1 nodo no es un clúster, 2 nodos son pocos (1 maestro y 1 trabajador, no hay posibilidad de escalar dentro del bloque, especialmente para opciones heterogéneas), 3 nodos se ven bien, pero no son múltiplos de 2 y la escalabilidad está limitada dentro del bloque, 6 nodos salen casi al precio de 7 nodos (en nuestra experiencia ya es un alto costo), 8 es demasiado, no cabe en el factor de forma mini ITX y es una solución aún más costosa para PoC.
Consideramos que cuatro nodos por bloque son el término medio ideal:
- menos materiales en la placa de clúster, por lo tanto, producción más económica
- múltiplo de 4, en total 4 bloques dan 16 procesadores físicos
- esquema estable de 1 maestro y 3 trabajadores
- más variaciones heterogéneas, módulos de computación general + computación acelerada
- factor de forma mini ITX con discos SSD y placas de expansión
Módulos de computación
La segunda versión se basa en CM4 y pensábamos que la lanzarían en factor de forma SODIMM. Pero...
Decidimos hacer una placa secundaria SODIMM y ensamblar el CM4 directamente en los módulos para que los usuarios no tuvieran que pensar en el CM4.
Módulo de Computación Turing Pi con soporte para Raspberry Pi CM4
En la búsqueda de módulos se descubrió todo un mercado de módulos de computación, desde pequeños módulos con 128 MB de RAM hasta 8 GB de RAM. A la vista, módulos de 16 GB de RAM y más. Para el alojamiento en el borde de aplicaciones basadas en tecnologías cloud native, 1 GB de RAM ya es poco, y la reciente aparición de módulos con 2, 4 e incluso 8 GB de RAM ofrece un buen espacio para el crecimiento. Se consideraron incluso opciones con módulos FPGA para aplicaciones de aprendizaje automático, pero su soporte se ha pospuesto porque el ecosistema de software no está desarrollado. Durante el estudio del mercado de módulos, llegamos a la idea de crear una interfaz universal para los módulos y en V2 comenzamos la unificación de la interfaz de los módulos de computación. Esto permitirá a los propietarios de la versión V2 conectar módulos de otros fabricantes y mezclarlos para tareas específicas.
V2 soporta toda la línea de Raspberry Pi 4 Compute Module (CM4), incluyendo versiones Lite y módulos de 8 GB de RAM.
Periférica
Una vez definido el proveedor de módulos y la cantidad de nodos, nos dirigimos al bus PCI, donde se encuentran los periféricos. El bus PCI es el estándar para dispositivos periféricos y está presente en casi todos los módulos computacionales. Tenemos varios nodos y, idealmente, cada nodo debería poder compartir dispositivos PCI en modo de solicitudes concurrentes. Por ejemplo, si se trata de un disco conectado al bus, debería estar disponible para todos los nodos. Comenzamos a buscar switches PCI con capacidad de soporte multi-host y descubrimos que ninguno de ellos se ajustaba a nuestros requisitos. Todas estas soluciones estaban principalmente limitadas a 1 host o múltiples hosts, pero sin el modo de solicitudes concurrentes a los endpoints. El segundo problema es el alto costo, a partir de $50 o más por chip. En V2 decidimos posponer los experimentos con switches PCI (volveremos a ellos más adelante a medida que avancemos) y optamos por asignar un rol a cada nodo: los primeros dos nodos expusieron un puerto mini PCI express por nodo, el tercer nodo expuso un controlador SATA de 2 puertos a 6 Gbps. Para acceder a los discos de otros nodos, se puede utilizar un sistema de archivos en red dentro del clúster. ¿Por qué no?
Sneakpeek
Decidimos compartir algunos esbozos de cómo ha evolucionado el bloque de clúster mínimo con el tiempo a medida que lo discutíamos y reflexionábamos.
Como resultado, llegamos a un bloque de clúster con 4 nodos de 260 pines, 2 puertos mini PCIe (Gen 2) y 2 puertos SATA (Gen 3). En la placa se ha instalado un switch gestionado de Capa 2 con soporte para VLAN. Desde el primer nodo se ha sacado un puerto mini PCIe, en el que se puede instalar una tarjeta de red para obtener otro puerto Ethernet o un módem 5G, convirtiendo así el primer nodo en un router para la red en el clúster y los puertos Ethernet.
El bus de clúster tiene más funciones, incluida la posibilidad de programar los módulos directamente a través de todas las ranuras y, por supuesto, conectores de ventilador en cada nodo con control de velocidad.
Aplicación
Infraestructura de edge para aplicaciones y servicios autohospedados
Diseñamos V2 con el objetivo de utilizarla como un bloque de construcción mínimo para infraestructura de edge de grado comercial/consumer. Con V2, es barato comenzar con la prueba de concepto y escalar a medida que crece, trasladando gradualmente aplicaciones que son económicamente y prácticamente más viables para hospedar en el edge. Los bloques de clúster se pueden unir, construyendo clústeres de mayor tamaño. Esto se puede hacer gradualmente sin grandes riesgos para los establecidos.
procesos. Ya hoy en día hay una gran cantidad de aplicaciones para negocios, .
Estación de trabajo ARM
Con una memoria RAM de hasta 32 GB en el clúster, se puede utilizar la primera nodo para la versión de escritorio del sistema operativo (por ejemplo, Ubuntu Desktop 20.04 LTS) y los otros 3 nodos para tareas de compilación, pruebas y depuración, desarrollo de soluciones nativas en la nube para clústeres ARM. Como nodo para CI/CD en la infraestructura periférica de ARM en producción.
El clúster Turing V2 con módulos CM4 es arquitectónicamente casi idéntico (la diferencia está en versiones menores de ARMv8) al clúster basado en instancias AWS Graviton. En el procesador de los módulos CM4 se utiliza la arquitectura ARMv8, puedes construir imágenes y aplicaciones para las instancias Graviton 1 y 2 de AWS, que son mucho más económicas que las instancias x86.
Fuente: habr.com
