Que tal gente, la semana pasada pase muchas horas en sesiones de tecnologías y arquitecturas que vienen y/o ya están dentro de VMware, todo esto dentro del marco de la conferencia de OCTO Global Field & Industry programa al que pertenezco como CTO Ambassador. Muchas de estas nuevas tecnologías y arquitecturas tienen como objetivo el habilitar mejor uso de recursos fisicos a través de agrupar y distribuir de manera centralizada (si, en esta industria vemos una y otra vez estos ciclos de innovación muy similares al pasado). Entre los muchos “WOW” que tuve durante esa semana se encuentra Bitfusion, adquisición de VMware hace unos cuantos meses, tenia un entendimiento conceptual de la solución pero realmente me impacto el como habilita el futuro de la plataforma vSphere.
¿Porque recursos de GPU distribuidos?
Creo que todos al día de hoy hemos escuchado de tecnologías, participado o liderado esfuerzos en temas de ML (Machine Learning), AI (Artificial Intelligence) y Big Data… ¿Pero que es lo que tienen en común todas estas tecnologías? el uso de GPUs. Los GPUs pueden procesar datos computacionales mucho más rápido que el de un CPU típico, ya que las GPUs tienen miles de núcleos dentro de cada acelerador. Como muchas nuevas tecnologías los GPUs han creado silos dentro del centro de datos (Sorprendente ¿No? jaja) creando problemas de gestión y una subutilización de estos recursos.
El acceso a GPUs no es algo nuevo dentro de vSphere, tenemos muchos casos de uso y múltiples métodos de acceso al hardware, VMDirectPath I/O y Horizon vGPU como ejemplos. Pero estos son casos de uso con recursos locales, lo que impone muchas limitantes de gestión, movilidad de las cargas, sub utilización y también limita casos de uso como lo son contenedores.
Aquí es donde entra Bitfusion, que permite crear un pool de recursos de GPU distribuidos, de manera tal que los clientes/aplicaciones que requieren acceso a dichos GPUs podrán consumirlos como si estos fueran locales dando un mucho mejor uso a la totalidad de los recursos disponibles. De esta manera las aplicaciones que requieren recursos de GPU pueden accesarlos a través de la red sin necesidad de tener un acceso físico directo, ejecutando los procesos requeridos y liberando dichos recursos para uso futuro, todo esto sin necesidad de re-arquitectar las aplicaciones y con un simple cliente de bitfusion.
Arquitectura y detalles tecnicos de Bitfusion
Ahora vamos a darle un vistazo a la arquitectura de Bitfusion que permite crear estos pooles para el acceso distribuido de GPUs:

Existen 3 componentes (a Febrero de 2020) que forman parte de la arquitectura:
- Servidor de FlexDirect – Esta VM o contenedor cuenta con todos los componentes de Bitfusion y además los componentes (Drivers) requeridos por el fabricante del GPU. Esta VM o contenedor nos dará los servicios de gestión (FlexDirect Manager) y básicamente se trata de la VM que tiene acceso directo al o los GPUs y donde definimos como se estarán entregando los recursos.
- Cliente de FlexDirect – Este es el componente que vive en la VM o Contenedor ejecuta la aplicación basada en CUDA o OpenCL, en este caso la capa de FlexDirect intercepta todas aquellas instrucciones basadas en CUDA u OpenCL y las transmite a través de la red a cluster de GPU de Bitfusion para que sean ejecutadas.
Como podemos ver la arquitectura es bastante simple, no se requiere de ningún tipo de driver para aceleración, tampoco el modificar la aplicación o librerias especificas, bitfusion trabaja de tal manera que la aplicación no se percata de esta “captura de I/O” y re direccionamiento de las mismas para ser ejecutadas en el cluster de GPUs:

Claramente existen consideraciones de diseño con bitfusion, entre las cuales se destacan:
- Medio físico de comunicación – Se recomienda 10Gbps pero claramente existen opciones como lo son Infiniband o Ethernet de 25, 40, 100Gbps. También podemos optar por RDMA o RoCE. Recuerden que no podemos vencer las leyes de la física :
- vnic – VMXNET3
- VMdirectPath I/O puede ser utilizado en el lado del cliente para contar con acceso a través de RoCE.