¿Por qué no hay software?

Durante décadas, hemos estado utilizando software para cortar servidores con hipervisores de virtualización para ejecutar muchas cargas de trabajo pequeñas en una pieza de hierro relativamente grande.

Esto fue una bendición para los servidores X86 durante la Gran Recesión, cuando la tecnología de virtualización de servidores estaba lo suficientemente madura como para ponerse en producción (aunque aún no era perfecta), lo que permitió la consolidación de servidores y una mayor utilización de servidores e incluso ayudó a algunas empresas a omitir una o dos generaciones de servidores. actualizaciones del servidor en un momento en que realmente no podían gastar el dinero en hierro nuevo.

Entonces, ¿cómo es que no usamos software para acoplar estrechamente muchos servidores baratos para crear fragmentos de memoria compartida y cómputo asociado para ejecutar cargas de trabajo más grandes que una sola máquina? Es mucho más fácil programar para un espacio de memoria compartida que para un sistema informático distribuido débilmente acoplado, por lo que esto es un poco desconcertante para nosotros. ¿No le gustaría tener una máquina con un puñado de sockets y miles de subprocesos y tener un software de bajo nivel que administre la asignación de recursos? ¿Por qué escalar sus aplicaciones y bases de datos cuando podría ser perezoso y escalar?

La tecnología para crear sistemas NUMA sobre la marcha existe desde hace muchos años. ¿Recuerda Virtual Iron, RNA Networks y ScaleMP? – y tal vez haya culminado con TidalScale, que ha estado probando otra vez la idea con sus propios giros sobre esencialmente la misma historia y que fue fundada en marzo de 2012 por Ike Nassi, Kleoni Ioannidou y Michael Berman.

Por cierto, esas otras tres empresas de software que crearon servidores NUMA virtuales a partir de máquinas X86 básicas ya no existen.

Virtual Iron, fundada en 2001, desapareció en las fauces abiertas de Oracle en mayo de 2009. RNA Networks, fundada en 2006, fue devorada por Dell en junio de 2011, y ese fabricante de servidores jugó un poco con eso y luego nunca supimos nada al respecto. de nuevo. Y ScaleMP, fundada en 2003, todavía se estaba fortaleciendo en el sector de HPC con su hipervisor NUMA del mismo nombre cuando se fundó The Next Platform en 2015, ScaleMP fue adquirida silenciosamente por SAP en junio de 2021. (No hubo ningún anuncio de esto hasta ahora). somos conscientes. )

Nassi es el bateador pesado en TidalScale y sigue siendo presidente y director de tecnología.

Después de obtener una licenciatura, una maestría y un doctorado en ciencias de la computación de la Universidad de Stony Brook en Nueva York, Nassi fue ingeniero en el innovador de minicomputadoras Digital Equipment, y en la década de 1980 fue vicepresidente en Encore Computer, el innovador de sistemas de supercomputación NUMA, antes de unirse a Apple para ayudar desarrollar su sistema operativo MacOS y sus lenguajes. (Nassi es uno de los creadores del lenguaje de programación Ada y ayudó a crear el lenguaje de programación Dylan para la computadora de mano Apple Newton). Fundó el pionero de las redes de malla Firetide en 2001, y luego pasó a ser científico jefe en el brazo de investigación de SAP de la Gigante del software ERP, en servicio desde 2005 hasta 2011.

Nassi también es profesor adjunto de informática desde hace mucho tiempo en la Universidad de California Santa Cruz.

TidalScale ha recaudado 43 millones de dólares en dos rondas de financiación de riesgo y, en 2016, incorporó a Gary Smerdon como director ejecutivo. Smerdon es un ejecutivo de semiconductores de AMD desde hace mucho tiempo que posteriormente trabajó en Marvell, Greenfield Networks (adquirida por Cisco Systems), Tarari (adquirida por LSI Logic, donde ocupó varios puestos ejecutivos durante seis años), Fusion-io y Pavalion Data Systems. .

Hablamos con Smerdon cuando se lanzó TidalScale 3.0, cuando estábamos haciendo Next Platform TV durante el apogeo de la pandemia de coronavirus. Y para nuestro disgusto, no le hemos dado a la compañía la cobertura adecuada de su lanzamiento TidalScale 4.0 el año pasado. Pero lo estamos haciendo durante el lanzamiento de TidalScale 4.1, que acaba de salir.

La compañía lanzó su HyperKernel inicial y la pila de administración de sistemas relacionada para servidores virtuales NUMA en 2016 y siguió con un lanzamiento 2.0 en 2017, pero fue con el producto TidalScale 3.0 en septiembre de 2019 que mejoró la escalabilidad de las máquinas NUMA que podrían estar compuestas con HyperKernel, con un máximo de 64 TB de memoria en un servidor NUMA definido por software, un máximo de 12 TB en cualquier nodo del clúster NUMA, hasta el punto en que se pueden direccionar 128 TB. Este es un límite en la arquitectura del servidor Xeon SP de Intel, que por el momento es la única CPU que admite TidalScale.

En teoría, no hay nada que impida que TidalScale sea compatible con las arquitecturas de CPU de servidor AMD Epyc, IBM Power o Arm con su HyperKernel. Pero en la práctica, una startup debe concentrarse y, a pesar de toda la competencia a la que se enfrenta Intel, la arquitectura Xeon SP sigue siendo la dominante en el centro de datos.

En un clúster NUMA de TidalScale, los nodos del servidor no tienen que tener la misma configuración en términos de cómputo o memoria. Con TidalScale 3.0, se permitía un máximo de 128 sockets en el clúster NUMA. Obviamente, con estos máximos, puede crear clústeres NUMA con una amplia variedad de nodos de servidor de forma asimétrica o puede crearlos como lo hacen los vendedores de clústeres basados ​​en hardware NUMA como HPE, IBM y otros con cada nodo en el clúster siendo el mismo.

Con el lanzamiento de TidalScale 4.0, todas estas capacidades se duplicaron. Por lo tanto, podría tener un máximo de 24 TB para cualquier nodo determinado, hasta 256 sockets y hasta 128 TB de memoria total en un clúster NUMA definido por software.

En cierto modo, TidalScale está empujando un poco contra la corriente del hardware. Y en varias otras formas de verlo, nunca ha habido un mejor momento para un "supervisor" o un "hiperkernel" o como quiera llamar el tipo de hipervisor que Virtual Iron, RNA Networks, ScaleMP y TidalScale tienen todo. creado individualmente.

Además, algunas de las innovaciones dentro de HyperKernel de TidalScale lo hacen único en comparación con sus predecesores, y mientras alguien no compre la empresa y se siente en ella, existe la posibilidad de que esta tecnología de agrupación en clústeres NUMA basada en software se vuelva más generalizada: particularmente con redes PCI-Express, Ethernet e InfiniBand que ofrecen un alto ancho de banda y baja latencia.

Primero, hablemos sobre la naturaleza de la computación y la agrupación en clústeres NUMA en el centro de datos actual y cómo mitiga la necesidad de NUMA en muchos casos.

Por un lado, los pocos diseñadores de CPU que quedan en el mercado de los centros de datos han estado implementando mejores y mejores diseños de hardware NUMA durante décadas, y esto realmente ha implicado agregar más interconexiones coherentes y más rápidas a medida que los transistores más pequeños permitieron que se metieran más cosas en la matriz. En este punto, apenas hay sobrecarga en un sistema NUMA de dos sockets, y los sistemas operativos que se ejecutan en el hierro X86 (Linux y Windows Server) se han ajustado hace mucho tiempo para aprovechar las ventajas de NUMA. Intel admite sistemas de cuatro y ocho sockets sin problemas, es decir, sin ningún conjunto de chips externo adicional.

Con sus próximos Xeon SP "Sapphire Rapids", esperamos al menos 60 núcleos utilizables por socket y ocho controladores de memoria DDR5 que podrán admitir quizás 4 TB por socket con tarjetas de memoria de 256 GB, posiblemente 8 TB por socket con memoria de 512 GB. palos Este es un socket muy denso en comparación con las generaciones anteriores de Xeon SP. E Intel admitirá NUMA de ocho vías sin cola, lo que debería significar admitir hasta 480 núcleos, 960 subprocesos y 64 TB sin cola. Ese es un nodo bastante gordo para los estándares modernos.

Con su servidor Power E1080 basado en Power10 "Denali", IBM puede admitir 240 núcleos que hacen aproximadamente el doble del trabajo de un núcleo X86, con 1920 subprocesos (IBM tiene subprocesos múltiples simultáneos de ocho vías en el Power10, como lo hizo con Power8 y Power9 chips), en 16 zócalos y hasta 64 TB de memoria física en esos zócalos. IBM tiene hasta 2 PB de direccionamiento virtual en la arquitectura Power10, por lo que puede hacer más memoria cuando lo desee y, hasta donde sabemos, no lo parece y no va a hacer DIMM diferenciales de 512 GB. basado en memoria DDR4; Los DDIMM de 256 GB son el máximo en este momento.

Estos servidores NUMA basados ​​en hardware no son baratos, razón por la cual HPE e IBM todavía los fabrican, a menudo para admitir bases de datos debajo de pilas de aplicaciones empresariales de back office masivas impulsadas por bases de datos relacionales. La base de datos en memoria de SAP HANA está impulsando muchas ventas de hierro de NUMA en estos días.

Pero el costo y la configuración rígida de los clústeres NUMA de hardware es lo que presenta una oportunidad para TidalScale incluso cuando cada socket se vuelve más poderoso y una cierta cantidad de NUMA está integrada en los chips. Y también lo hace un invento en el corazón de TidalScale HyperKernel llamado CPU virtual errante.

En las arquitecturas NUMA basadas en hardware que proporcionan un espacio de memoria compartido y dividido por un hipervisor de virtualización de servidor, las máquinas virtuales se configuran con cómputo, memoria y E/S y se anclan a esos recursos. Cualquier dato fuera de la configuración de esa VM debe paginarse en esa VM, y esto crea latencia.

Con HyperKernel, Nassi y su equipo crearon un nuevo tipo de CPU virtual, uno que no es un programa que se ejecuta en un hipervisor dividido, sino una abstracción computacional de bajo nivel que tiene un conjunto de registros y punteros asignados. Esta es una abstracción muy pequeña: una o dos páginas de memoria que caben dentro de un paquete Ethernet. Hay miles de millones de estas CPU virtuales creadas a medida que se ejecutan las aplicaciones, y en lugar de mover datos a máquinas virtuales grandes, estas CPU virtuales revolotean alrededor de los nodos del servidor y a través de los nodos vinculados a las redes en el clúster NUMA definido por software, moviéndose a donde el datos es que necesitan realizar la siguiente operación en una aplicación.

Esta arquitectura de vCPU errante se describe en detalle en este documento técnico, pero aquí está el quid de la cuestión: "Cada vCPU en un sistema TidalScale se mueve a donde puede acceder a los datos que necesita, donde sea que se encuentren físicamente esos datos. Cuanto más grande sea el sistema TidalScale, Cuantas más CPU físicas y RAM estén disponibles para sus deambulaciones, y más eficiente se vuelve la vCPU deambulante en comparación con las otras opciones para procesar una gran cantidad de datos".

Las eficiencias se obtienen, en parte, con algoritmos de aprendizaje automático que estudian los patrones de computación y acceso a datos en aplicaciones y bases de datos en ejecución, y las vCPU se pueden agregar y enviar a datos, al igual que una unidad matemática vectorial puede agrupar datos y masticarlos en paralelo.

La red de esto es que para aquellos que necesitan un espacio de memoria compartida de un gran servidor NUMA, para ejecutar un sistema de gestión de base de datos pesado o análisis en memoria, por ejemplo, los clientes pueden crear uno a partir de servidores Xeon SP normales y conmutación Ethernet, y ahorre dinero en comparación con los sistemas NUMA basados ​​en hardware.

"Los clientes nos han dicho que reducimos su costo total en alrededor de un 50 por ciento", le dice Smerdon a The Next Platform. "Y en comparación con IBM Power Systems, creo que el ahorro total es mucho mayor, probablemente del orden de un 60 a un 75 por ciento menos de costos en general".

Podemos pensar en otros casos de uso, como los que perseguía ScaleMP hace una década. En muchos clústeres de HPC, hay cientos o miles de nodos X86 de dos sockets y luego docenas de nodos X86 de gran memoria basados ​​en hierro NUMA más pesado para aquellas partes de la carga de trabajo que requieren más capacidad de memoria para funcionar bien.

Imagínese si estos grandes nodos pudieran configurarse sobre la marcha según sea necesario a partir de servidores básicos de dos sockets. Mejor aún, podría crear un grupo de nodos de memoria realmente gruesos, o una combinación de nodos de memoria delgados y gruesos, según sea necesario. A medida que cambian las cargas de trabajo, la configuración del clúster NUMA podría cambiar.

¿Cuál es la parte menos confiable de un servidor? es procesador? ¿Es el software del sistema? es red? No. Es la memoria principal. Y a medida que la memoria principal se vuelve más y más densa, cada vez es más fácil que un rayo cósmico o una partícula alfa cambien bits y causen todo tipo de estragos.

DRAM se está volviendo cada vez menos confiable, dice Smerdon, a medida que aumenta la capacidad en un chip DRAM, citando una cifra de confiabilidad 5.5 veces menor de un estudio de AMD de 2017. Al mismo tiempo, la cantidad de memoria principal en el servidor se ha ido. por un factor de 10X, y extrañamente, debido a que Intel tuvo que modificar los controladores de memoria para admitir la memoria principal Optane 3D XPoint, una de las cosas que hizo fue retroceder los bits de corrección de errores para poder calzar Optane en la arquitectura, lo que resultó en un tasa más alta de errores incorregibles en tiempo de ejecución en la memoria para los chips Xeon SP. Cuando se multiplica todo eso, dice Smerdon, la memoria tiene una tasa de fallas en un servidor Xeon SP que es aproximadamente 100 veces más alta que hace una década.

Y hay todo tipo de historias de terror relacionadas con esto, que no se pueden mitigar fácilmente diciendo que estos errores pueden cubrirse con los mecanismos de tolerancia a fallas inherentes a las plataformas informáticas distribuidas modernas. Sin dar nombres, Smerdon dice que un hiperescalador tuvo que reemplazar 6000 servidores con más de 40 PB de memoria principal debido a las altas tasas de fallas. (No es de extrañar, entonces, que la arquitectura AMD Epyc se esté comiendo cuota de mercado entre los hiperescaladores y los constructores de nubes).

La buena noticia es que los errores corregibles de DRAM, las fallas de la fuente de alimentación y del ventilador, y la pérdida de conexión de la red y el almacenamiento y las fallas del dispositivo tienen una alta probabilidad de ocurrir y todos brindan algún tipo de advertencia a través de la telemetría del sistema de que se avecina un bloqueo. . Y en un clúster NUMA virtual con muchos nodos, cuando se produce una advertencia de este tipo, tiene la oportunidad de mover las cargas de trabajo y los datos de ese servidor a una máquina adyacente antes de que ocurra el bloqueo. Arregla el servidor, o lo reemplaza, lo conecta, deja que HyperKernel se haga cargo y vuelve a estar en acción.

Eso, en pocas palabras, es lo que hace la función TidalGuard de TidalScale 4.1, recién lanzada. El tiempo de inactividad es costoso, por lo que evitarlo es importante. Smerdon dice que el 85 por ciento de las corporaciones necesitan tener un mínimo de "cuatro nueves" de disponibilidad para sus sistemas de misión crítica, y eso significa tener sistemas redundantes y replicados. Esto es costoso, pero vale la pena dado que un tercio de las empresas encuestadas por TidalScale dicen que una hora de inactividad cuesta $ 1 millón o más, e incluso las empresas más pequeñas dicen que pierden al menos $ 100,000 por hora que sus sistemas están fuera de línea.

Al usar TidalGuard en HyperKernel, el tiempo medio para reparar un sistema es de unos diez minutos, un factor de mejora de 10X a 1000X sobre otros métodos, y los clientes pueden agregar otros "dos nueves" de disponibilidad a su infraestructura.

Y TidalGuard también puede abordar un problema del que no hemos hablado mucho, que es la nivelación del desgaste del servidor en el centro de datos.

"Sabes que tienes que rotar los neumáticos y todos estamos familiarizados con el hecho de que la memoria flash tiene que equilibrar la nivelación del desgaste o no funciona", explica Smerdon. "Ahora los servidores, su memoria principal, en realidad, se están desgastando a un ritmo cada vez mayor, pero no se ha monitoreado esto. Pero podemos monitorear esto en nuestros clústeres y, según el estado del uso, podemos estimar entre un grupo a qué servidores les queda más vida y priorizar el uso en ellos primero".

Y con esta función, puede comenzar a predecir cuándo necesitará una nueva flota y cuánto tiempo podría durar.

Curiosamente, la confiabilidad, el tiempo de actividad y la agilidad son las principales razones por las que las empresas están implementando TidalScale hoy, y la escalabilidad y el ahorro de costos son prioridades secundarias.

Si el agrupamiento NUMA definido por software finalmente despega, y creemos que podría ser una herramienta importante en la caja de herramientas de infraestructura componible, entonces TidalScale podría convertirse en un objetivo de adquisición. Y dado el tiempo que ha estado en el campo y que no hemos oído hablar de implementaciones generalizadas de su tecnología, apostaríamos a que TidalScale estaría ansioso por ser adquirido por un proveedor de TI mucho más grande para ayudar a impulsar la adopción de manera más amplia.

Si Intel no ha devuelto algunos bits de memoria a la DRAM con Sapphire Rapids Xeon SP, Intel podría estar interesado en adquirir TidalScale para ayudar a corregir este problema. Pero eso significaría admitir que creó un problema en primer lugar, por lo que parece poco probable.

Dado que AMD se limita a máquinas de uno y dos sockets, puede interesar. El colectivo Arm también podría usar servidores NUMA virtuales, al igual que uno de los proveedores de la nube que no desea comprar servidores distintos de cuatro y ocho sockets para sus flotas. (Amazon Web Services ha estado jugando con TidalScale internamente, y sin duda otros hiperescaladores y desarrolladores de la nube también lo han hecho). VMware, en busca de un nuevo ángulo en la virtualización de servidores, podría estar interesado, y lo mismo ocurre con los fabricantes de servidores como HPE, Dell, y lenovo.

Presentando aspectos destacados, análisis e historias de la semana directamente de nosotros a su bandeja de entrada sin nada en el medio. Suscríbase ahora