Ir al contenido principal
BlogComputaciónCómo Linode pasó del hardware a las GPU en seis semanas

Cómo Linode pasó del hardware a las GPU en seis semanas

Linode GPUs en la nube

En 2019, tres departamentos de la empresa fijaron un objetivo: lanzar nuevas GPU antes del aniversario de Linode. Lo hablamos con los equipos de hardware, marketing y gestión y no sabíamos si podríamos logarlo, ya que en ese momento también estábamos desarrollando otros productos.

Por eso decidimos crear un equipo independiente formado por personas de varios departamentos. Así fue como nació el equipo «Misión GPU». Ahora, casi dos años después de todo aquello y muchas implementaciones de GPU después, queremos viajar al pasado para analizar en profundidad cómo logramos convertir una idea en un producto bien logrado que crece cada día más.

Breve historia de la virtualización en Linode

Antes de ahondar en el lanzamiento propiamente dicho, queremos dar un breve repaso por las cuestiones técnicas y la historia de cómo surgió la virtualización en Linode cuando aún no éramos el proveedor que conoces hoy en día.

Linode nació en 2003 como una empresa pequeña que ofrecía máquinas virtuales con UML («User-Mode» de Linux), un paradigma similar a QEMU («Quick Emulator») que era capaz de ofrecer un hardware totalmente virtualizado. Cuando los clientes accedían al Linode, lo que veían (discos, redes, placas base, RAM, etc.) se comportaba como dispositivos físicos, pero, en realidad, se ejecutaban en un software.

Varios años después, Linode pasó a Xen como su capa de virtualización para ofrecer las últimas mejoras de rendimiento a nuestros clientes. Xen es un hipervisor de tipo 1, lo que significa que el hipervisor se ejecuta directamente en el hardware, y los invitados se ejecutan sobre el kernel Xen . El kernel Xen proporciona paravirtualización a sus huéspedes, o sea que las interfaces de hardware que ve el Linode se traducen a llamadas reales a la máquina a través del kernel Xen y se devuelven al usuario. La razón por la que existe esta capa de traducción es para proporcionar seguridad y otras características de seguridad para que la instrucción correcta vaya a la Linode correcta.

Varios años después, se desarrolló una nueva tecnología llamada KVM (Kernel Virtual Machine). KVM consiste en partes del kernel de Linux que proporcionan interfaces paravirtuales a las instrucciones de la CPU. Qemu es una de las tecnologías de virtualización que puede aprovechar KVM. Linode decidió cambiar de nuevo en beneficio de nuestros clientes. Cuando los clientes realizaron la actualización gratuita a KVM , la mayoría de las cargas de trabajo vieron un aumento instantáneo del rendimiento. Este tipo de paravirtualización es diferente de Xen: las instrucciones de la CPU pasan del huésped (Qemu) al núcleo anfitrión y directamente a la CPU utilizando las instrucciones de nivel de procesador, lo que permite velocidades de ejecución casi nativas. Los resultados de esas instrucciones se devuelven a la Linode que las emitió, sin la sobrecarga que requiere Xen .

¿Y eso qué tiene que ver con las GPU?

Hicimos un estudio de mercado para saber qué podíamos ofrecer a los clientes que querían ejecutar cargas de trabajo con una GPU. Al final, decidimos ofrecerles las GPU directamente a través de una tecnología llamada «acceso directo al host». Le decimos a QEMU a qué dispositivo queremos asignar el acceso directo (en este caso, la GPU) y ellos, junto con Linux, lo aíslan para que ningún otro proceso del sistema pueda utilizarlo, ni la máquina que ejecuta Linux ni el resto de Linodes. Solo el cliente tiene acceso exclusivo a la GPU. Al ser el dispositivo físico el que se aísla, sin alterarse ni paravirtualizarse, no es necesaria la fase de traducción.

Semana 1: el hardware llega a Linode

Una vez hecha la investigación, el equipo decide ponerse manos a la obra con el proyecto. Para que el plan funcionara, había que hacer algunos cambios en los programas de los niveles más bajos del sistema. El hardware llegó un lunes y teníamos cinco días para decidir si queríamos avanzar y hacer un pedido bastante grande a un centro de datos para cumplir el plazo de entrega.

Todos los miembros del equipo pensamos lo mismo: «si no podemos hacer que funcione en una semana de 40 horas de trabajo, no vamos a avanzar». No es que fuéramos a hacer horas extra, pero teníamos solo cinco días para decidir el futuro de un nuevo producto.

¿Y qué pasó al final? Que la fase de investigación nos salvó la vida. Hicimos las cosas tal como habíamos leído y funcionó a la perfección. En cuestión de días vinculamos las GPU a los Linodes en un entorno de prueba y cuando llegó el viernes, ya teníamos la certeza de que iba a funcionar. ¡La prueba había salido bien! Así que lo siguiente era hacer ese gran pedido y seguir avanzando.

Semana 2: hacer que la interfaz del hardware funcione con las GPU

Tras el éxito de la semana anterior, llegamos el lunes a la oficina con las pilas recargadas y listos para integrar el proceso de vinculación de las GPU en los flujos de creación de Linode. Siempre intentamos que las interfaces sean lo más simples posible y que con un par de clics se pueda implementar un Linode. Y eso es algo que conlleva un gran esfuerzo.

Para que las GPU funcionaran correctamente, teníamos que escribir e implementar algunas piezas de nivel bajo (por ejemplo, aislar la RAM de la GPU y el Linode) y asignarle al Linode núcleos exclusivos de la CPU que, a su vez, estaban conectados con la RAM aislada y la GPU. Estudiamos la arquitectura NUMA (memoria de acceso no uniforme) de la placa madre y logramos asignar de forma exclusiva el grupo NUMA de la RAM a la CPU más cercana y el grupo NUMA asociado al PCIe Express en el que estaba conectada la GPU. Eso nos permitió implementar un Linode con 1, 2, 3 o 4 GPU asociadas y aprovechar la parte de la RAM y los núcleos de la CPU que, dentro de la estructura de la placa madre, estaban vinculados con la GPU.

Una vez terminada la capa de hardware, trabajamos en la interconexión con los mecanismos de Job Queuing de Linode para poder arrancar Linodes a través de nuestro Cloud Manager y API. En esta fase, pudimos empezar a hacer pruebas de fiabilidad. Lo último que queríamos era que un ingeniero de guardia recibiera un aviso en mitad de la noche debido a un fallo del sistema, o que un sistema se cayera en mitad de la jornada laboral para un cliente en una zona horaria diferente. Teniendo en cuenta los horarios de sueño tanto de los clientes como de los ingenieros, empezamos las pruebas con antelación y seguimos asegurándonos de que los clientes recibieran un producto sólido y fiable.

Semana 3: cambios en la interfaz de administración y la forma de control

Durante la tercera semana tuvimos que abordar algunas cuestiones administrativas: ¿cómo sabremos qué Linode tiene cada cliente? ¿Cómo podemos evitar enviarles a una instancia de Linode sin GPU?

Poniendo en práctica medidas de seguimiento y control. Así podríamos saber cuántas GPU tenemos, cuántas están ocupadas, cuántas están vacías y cuántas podemos vender a los clientes. También tuvimos que incorporar una herramienta de seguimiento de las GPU en las interfaces de administrador. Puede parecer una tarea aburrida, pero todo el equipo tuvo que ponerle mucho ingenio e, incluso, recurrir a personas ajenas para conectar este nuevo producto con el ecosistema de la empresa sin tener que recurrir a procesos manuales.

Por suerte, juntos logramos escribir el código y probarlo para saber que funcionaba bien y que no hacía falta intervenir de forma manual para ejecutar una instancia de GPU. Hacer todo eso durante esta etapa también simplificó mucho la fase de prueba, puesto que solo teníamos que hacer clic en un botón de la interfaz del administrador para activar una instancia de GPU.

Semana 4: Hacer cambios en la página web pública API para que los clientes puedan crear Linodes

Después de crear el botón de la interfaz del administrador para que aparezca una instancia de GPU de Linode , nos sentimos bastante bien. Ahora, teníamos que trabajar para exponer esta misma funcionalidad a los clientes. El sitio público API está respaldado por Python, lo que hizo que el código fuera extremadamente intuitivo. Pudimos desplegar los cambios y probarlos muy rápidamente. La parte complicada era hacer que esta función estuviera disponible dentro de la empresa para probarla, pero que no estuviera disponible fuera de la empresa hasta que hubiéramos hecho las pruebas necesarias por motivos de fiabilidad.

Semana 5: ¡implementación! O, más bien, cómo implementar una función pública a través de un botón de activación

La clave está en hacerlo con tiempo y muchas veces.

Ya no nos quedaba mucho tiempo, así que nos preguntamos: ¿estamos listos para hacerlo público y luego ponerlo a disposición de los clientes?

La clave estaba en abordar las posibles fallas desde el principio y probar la implementación muchas veces. Para ello, cuando aún estábamos en la fase de prueba dentro del equipo, implementamos las instancias de GPU de cara al público ocultas en un botón de activación. Eso nos permitió probar las GPU en nuestras cuentas de empleados y tener la misma experiencia de uso que nuestros futuros clientes. Cada vez que nos topábamos con un error inesperado, lo arreglábamos y volvíamos a implementarlo.

Y así, sin prisa pero sin pausa, y reescribiendo el código casi todos los días, nos quedamos sin problemas en la lista. Cuando ya no teníamos nada que cambiar, decidimos ponerlo a disposición de los clientes.

Semana 6: ¡pruebas! Hacer que los empleados de Linode prueben las GPU

Una de las ventajas de trabajar en Linode es que podemos trastear con tecnología de vanguardia antes de que salga al mercado (guiño guiño: ¡estamos buscando personal!). Así, cada uno puede usar el producto a su ritmo y eso nos da la tranquilidad de que está más que probado. Les damos la posibilidad de probar la instancia de GPU en horario de oficina o fuera de él (si quieren) como si fueran clientes a través de sus cuentas de trabajo.

Estos son algunos usos que les dieron a las GPU:

  • Juegos en la nube: el juego se ejecuta en la instancia de GPU y el vídeo y los controles se transmiten por Steam Link™.
  • Renderización 3D
  • Transcodificación de vídeo
  • Prueba de seguridad de las contraseñas
  • Ejecución de TensorFlow

Después de esta etapa, recopilamos las métricas de rendimiento y decidimos que estábamos listos para pasar a la producción y el lanzamiento a los clientes.

¡Lanzamiento!

¡Lanzamos el producto! ¡Y lo celebramos a lo grande! ¡Hubo helado y merchandising! Los clientes empezaron a probar el producto que habíamos desarrollado durante las semanas previas y lo mejor es que todo salió de maravilla. No tuvimos que hacer cambios de último minuto, nada voló por los aires, los clientes estaban contentos y todo salió bien.

El lanzamiento del código en sí no fue difícil. Desde el punto de vista del código y la configuración del sistema, todo lo que se necesitó para lanzar las GPU a la producción fue la eliminación de una bandera de características. Pero también hay muchas otras cosas que intervienen en el lanzamiento de un producto en Linode: la documentación técnica, la realización de cambios en la interfaz de usuario en Linode Cloud Manager , y todo el material de marketing divertido para ayudar a celebrar nuestro nuevo producto.

¿Y después? No hicimos ningún cambio durante 6 meses

Hay dudas que nos asaltan constantemente: ¿hicimos suficientes pruebas? ¿Seis semanas es poco tiempo?

En nuestro caso, fue la velocidad justa: no he tenido que tocar el código desde el lanzamiento. Además, las GPU de Linode han sido utilizadas por los clientes todos los días. Es estupendo poder construir un producto y que funcione, y luego seguir construyendo otros grandes productos, y que esa cosa que construiste hace dos años siga funcionando, por sí sola, con una mínima interacción necesaria

En retrospectiva, creemos que esto es lo que nos llevó al éxito:

  1. Investigar con tiempo: eso nos ayudó a resolver problemas inesperados sin tener el hardware.
  2. Trazar un plan: respetar los plazos de cada tarea fue lo que nos hizo lanzar el producto a tiempo.
  3. Respetar el plan: céntrate en lo que estás haciendo y no pierdas de vista las tareas pendientes.
  4. Tener un buen equipo de gestión: es importante que todo el equipo directivo sepa que, cuando hablamos de proyectos de ejecución rápida, es esencial respetar los plazos para poder lanzar el producto. Este punto en particular es el más importante. Y, si bien tener un poco de presión te motiva (como fue nuestro caso), si te presionan demasiado acabas agotado y cometes errores. Para evitarlo, presentamos el calendario al equipo directivo y quedaron más que satisfechos.
  5. Trabajar en equipo: de no haber tenido el apoyo de toda la organización, el equipo a cargo del proyecto no podría haber logrado su objetivo. Cuando todos vamos en la misma dirección, nos ayudamos entre nosotros y eso marca la diferencia.
  6. Hacer pruebas: pruebas, pruebas, pruebas... ¡PRUEBAS! Tanto automatizadas como manuales. Ese fue el motivo principal por el que mi equipo no tuvo que tocar el código en más de 6 meses.

Echa un vistazo a la documentación sobre las GPU para obtener más información. Ahora este servicio está disponible en los centros de datos de Newark, Bombay y Singapur.

¿Quieres probar las GPU de Linode con tus cargas de trabajo? Accede a una prueba gratuita de una semana. Obtén más información.

(Y si quieres ayudarnos a desarrollar y probar productos como las GPU, ¡estamos buscando personal!).

Comentarios (1)

  1. Author Photo

    how to make windows os in linode

Dejar una respuesta

Su dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *.