Clústeres para computación técnica a gran escala en la nube

En esta solución, se proporciona orientación para llevar a cabo computación técnica a gran escala en Google Cloud. Muchas apps de computación técnica requieren un gran número de nodos de procesamiento individuales conectados entre sí en un clúster, además de la coordinación de la computación y el acceso a los datos a través de los nodos.

Los conceptos y las tecnologías subyacentes a la computación en clúster se desarrollaron en las últimas décadas y ahora ya están elaborados y establecidos por completo. La migración de la pila de software a Google Cloud puede agregar algunos giros inesperados, pero también ofrece una serie de oportunidades para reducir los costos y aliviar los cuellos de botella existentes en los entornos de computación de alto rendimiento actuales. En esta guía, se proporciona una descripción general de las tecnologías, los desafíos y la cantidad actual de soluciones para ejecutar clústeres de computación en Google Cloud.

La computación en clúster agrega y coordina una colección de máquinas que trabajan en conjunto en la resolución de una tarea. Los clústeres suelen tener un solo nodo principal (a veces llamado nodo superior), cierta cantidad de nodos de procesamiento y, a veces, otros nodos especializados. El nodo principal es el cerebro del sistema y es responsable de lo siguiente:

  • Registrar nodos de procesamiento en el sistema
  • Supervisar los nodos
  • Asignar trabajos a nodos particulares
Un clúster se compone de un nodo principal y un conjunto de nodos de procesamiento.
Figura 1. Un clúster se compone de un nodo principal y un conjunto de nodos de procesamiento. Los usuarios interactúan con el nodo principal, que luego coordina el trabajo con los nodos de procesamiento.

Los usuarios envían trabajos que se componen de muchas tareas, en que una tarea es la unidad básica de trabajo. Algunas aplicaciones requieren que todas las tareas de un trabajo se ejecuten simultáneamente y permiten que las tareas se comuniquen para ejecutar un algoritmo paralelo; algunos trabajos tienen un conjunto complejo de dependencias de tareas, de modo que las tareas particulares deben ejecutarse antes que otras; y algunas tareas pueden requerir configuraciones de nodo particulares en términos de memoria, CPU o algún otro hardware particular en el que se ejecuten. Las tareas son archivos ejecutables que leen los datos de entrada del almacenamiento, procesan los datos para producir un resultado y, luego, vuelven a escribir los resultados finales en el almacenamiento.

Hay dos tipos principales de cargas de trabajo de computación en clúster:

  • Computación de alto rendimiento (HPC): Un tipo de computación que usa muchos nodos trabajadores, estrechamente acoplados y que se ejecutan simultáneamente para realizar una tarea. Estas máquinas normalmente necesitan una latencia de red baja para comunicarse de forma efectiva. Las aplicaciones de ejemplo en este espacio incluyen modelado del clima, dinámica de fluidos computacional (CFD), modelado de esfuerzo en ingeniería y diseño electrónico.

  • Computación de alta capacidad de procesamiento (HTC): Un tipo de computación en que las aplicaciones tienen múltiples tareas que pueden procesarse de forma independiente entre sí, sin necesidad de que los nodos de procesamiento individuales se comuniquen. A veces, estas cargas de trabajo se denominan cargas de trabajo embarazosamente paralelas o por lotes. Los ejemplos típicos incluyen procesamiento de medios, transcodificación, genómica, y simulación y procesamiento de eventos de física de partículas. Si necesitas procesar muchos archivos individuales, probablemente sea una carga de trabajo de HTC.

Pila de software de computación en clúster

Una pila de software de computación en clúster se compone de los siguientes elementos:

  • Software de administración de sistemas que aprovisiona y compila clústeres.
  • Programadores que organizan la ejecución del trabajo.
  • Aplicaciones de usuario final.

Las siguientes secciones hablan del software de administración del sistema y de los programadores.

Software de administración del sistema

Puedes ejecutar el software de agrupamiento en clústeres directamente en el hardware sin sistema operativo, como en los clústeres locales o en entornos virtualizados, como en los entornos de nube. La organización manual de varios nodos en un clúster requiere mucho tiempo y es propensa a errores. Puedes usar un software especializado de administración de clústeres para aprovisionar y configurar varios nodos y recursos, juntos, de manera repetible y determinista.

El software de código abierto ElastiCluster de la Universidad de Zúrich ofrece un enfoque nativo de la nube para la administración de clústeres con asistencia a nodos de aprovisionamiento, mediante el uso de Compute Engine y la configuración de nodos mediante un conjunto de guías de Ansible. ElastiCluster aprovisiona los nodos y, luego, instala una pila de software base, incluido NFS para la entrega de archivos, la administración de cuentas de usuario NIS y un programador de trabajos que ejecuta aplicaciones de usuario. Es compatible con una variedad de programadores y se puede usar fácilmente de forma inmediata o personalizar para satisfacer las necesidades de los equipos pequeños y medianos.

Si usas otros sistemas de administración de configuración para administrar tus clústeres de HPC, como Chef, Puppet o Terraform, puedes aprovechar esas inversiones a medida que migras a Google Cloud mediante las herramientas y los complementos disponibles.

Google Cloud proporciona servicios nativos para implementar y aprovisionar sistemas de software de múltiples nodos. Cloud Deployment Manager te permite aprovisionar un conjunto de recursos en la nube, como Compute Engine, los grupos de instancias administrados de Compute Engine y Cloud Storage. El instructivo de HTCondor te muestra cómo usar Cloud Deployment Manager y los grupos de instancias administrados para aprovisionar y configurar un clúster.

Programadores de trabajo

Una vez que el clúster está operativo, el software que administra la ejecución de la tarea y la asignación de nodos se denomina programador de trabajos (a veces llamado administrador de carga de trabajo o administrador de colas). A menudo, un administrador de clúster viene con un programador de trabajos integrado. Los programadores de trabajo ofrecen una variedad de capacidades para ayudar a administrar trabajos y tareas, como las siguientes:

  • Asistencia para prioridades de trabajo entre usuarios y grupos, que ayuda a proporcionar una programación de trabajos basada en políticas
  • Asistencia para tareas con errores cuando se ponen en cola y se vuelven a programar las tareas
  • Consideración de dependencias de tareas y necesidades de recursos para la asignación de tareas
  • Escalamiento del tamaño del clúster según la cantidad de trabajos en la cola

Hay una variedad de administradores de carga de trabajo comerciales y de código abierto populares. Dentro de los ejemplos, se incluyen HTCondor de University of Wisconsin, Slurm de SchedMD, Univa Grid Engine y LSF Symphony de IBM. Cada uno tiene sus fortalezas.

HTCondor se compila con una filosofía de nada compartido y se puede usar en recursos compartidos para programar trabajos de manera oportunista en recursos que, de otra manera, estarían inactivos. Proporciona su propio movimiento de datos y, por lo tanto, no requiere sistemas de archivos compartidos. Como resultado, escala a cientos de miles de núcleos y se puede usar en múltiples zonas y regiones. HTCondor se ha usado para cargas de trabajo híbridas, en las cuales el trabajo se comparte o se divide entre sistemas locales y basados en la nube. Sin embargo, como su nombre lo indica, se enfoca en trabajos de alta capacidad de procesamiento, no en trabajos paralelos estrechamente acoplados.

Slurm y Univa Grid Engine proporcionan un entorno de clúster de HPC más tradicional, que admite aplicaciones paralelas de alta capacidad de procesamiento y alto rendimiento. Ambos suponen un sistema de archivos compartidos entre los nodos, lo que elimina la necesidad de mover los datos. Ambos proporcionan un entorno de usuario cómodo y familiar para desarrollar apps porque, a menudo, son las mismas herramientas locales. Estos programadores de trabajo tradicionales son suficientes para clústeres pequeños a medianos, pero a medida que aumenta el tamaño del clúster, la carga en el servidor de archivos se convierte en un cuello de botella para el rendimiento. Los sistemas de archivos paralelos y distribuidos (ver la siguiente sección) pueden ayudar con este problema cuando se encuentran a gran escala. Como alternativa, cuando no se requiere acceso de baja latencia a archivos, puedes aprovechar Cloud Storage, que proporciona acceso a objetos paralelos mediante la API o a través de gcsfuse, que requiere compatibilidad con POSIX.

Por último, Google Cloud incluye un servicio sencillo con el fin de programar una tarea basada en Docker en Compute Engine para cargas de trabajo de alta capacidad de procesamiento: la API de Pipelines de Cloud Life Sciences. Este servicio requiere dividir el trabajo en tareas, administrar las dependencias entre tareas y administrar el ciclo de vida de la tarea. El proyecto de código abierto dsub proporciona una herramienta de línea de comandos para iniciar trabajos por lotes y es compatible con la API de Pipelines de Cloud Life Sciences.

Almacenamiento

La mayoría de las aplicaciones de HPC requieren una solución de almacenamiento de archivos que admita la API de POSIX. Para los clústeres más pequeños, FileStore proporciona un servicio de almacenamiento de archivos basado en NFS y administrado por Google. Sin embargo, para clústeres más grandes, la E/S de la aplicación puede convertirse en el cuello de botella del rendimiento. Los sistemas de archivos paralelos y de escalamiento horizontal, como Elastifile (adquirido por Google), Lustre o Quobyte, ayudan a escalar a clústeres grandes (o incluso a clústeres de E/S más pequeños pero de mayor peso).

Como alternativa, cuando no se requiere el acceso de baja latencia a archivos, puedes aprovechar Cloud Storage, que proporciona acceso a objetos paralelos mediante la API o gcsfuse, que requiere compatibilidad con POSIX.

Oportunidades para computación en clúster en la nube

Hay muchos motivos para ejecutar clústeres de computación en la nube:

  • Tiempo de solución. Lanzar un clúster de calidad de producción en la nube solo toma unos pocos minutos, desde un pequeño clúster de 10 nodos con cientos de núcleos disponibles, hasta clústeres de gran escala con cien mil o más núcleos. En contraste, la compilación de nuevos clústeres locales puede tardar meses en estar lista para operación. Por lo general, incluso cuando los clústeres locales están disponibles, tienen un uso alto y tiempos largos de espera en cola (a veces horas o días) antes de que se programen los trabajos para ejecutarse. En su lugar, puedes compilar tus propios clústeres en la nube, usarlos para tus cargas de trabajo y terminar los clústeres cuando finalice tu análisis.

  • Costo total de propiedad más bajo. Google Cloud no solo reduce el tiempo de solución, sino que también puede reducir el costo total por ejecución, puesto que aprovecha las instancias de VM interrumpibles, los descuentos de uso a largo plazo y el escalamiento dinámico. Puedes agregar nodos cuando los trabajos estén en cola y quitarlos cuando no sean necesarios.

  • Asistencia para colaboración. En muchas situaciones, el análisis de computación se desarrolla en colaboración con diferentes personas en varias organizaciones. Google Cloud proporciona herramientas de administración de identidades y accesos a nivel de proyecto para permitir el acceso controlado a datos y herramientas analíticas. Los usuarios autorizados pueden acceder a los mismos datos, apps y clústeres para garantizar que todos estén ante el mismo contenido sin tener que copiar datos, administrar versiones o sincronizar parámetros de configuración de clústeres.

  • Recursos adaptados a la tarea. Debido a que el costo de un trabajo depende solo de las horas centrales totales, en lugar del número de instancias, la ejecución de clústeres en la nube permite que cada equipo o grupo tenga su propio clúster exclusivo. Este enfoque puede aliviar otro punto importante del desarrollo de políticas en torno al uso de varios grupos. Luego, se puede personalizar cada clúster de nube dedicado a fin de ajustarlo a la app de destino. Los clústeres locales suelen formar parte de un recurso único que se comparte entre los distintos grupos y apps. En ese entorno, suele ser complicado configurar y mantener las políticas para compartir entre los grupos.

  • Integración. Antes de poder ejecutar grandes trabajos de computación, los investigadores realizan un trabajo importante para preparar los conjuntos de datos. Después de pasar a la nube, estos investigadores pueden aprovechar las herramientas de macrodatos disponibles en la nube. Los resultados de los sistemas de computación también se tienen que analizar. Las herramientas como BigQuery y Datalab pueden proporcionar ventajas significativas en comparación con las herramientas disponibles en los sistemas locales.

Los clústeres locales típicos se comparten entre usuarios y grupos, y son compatibles con muchas necesidades de apps diferentes.
Figura 2. Los clústeres locales típicos se comparten entre usuarios y grupos, y son compatibles con muchas necesidades de apps diferentes. Por el contrario, cuando se pasa a Google Cloud, los usuarios pueden personalizar las propiedades del clúster para que coincidan con las necesidades de la app a fin de reducir los costos y aumentar el rendimiento.

Consideraciones de la arquitectura

Si bien las ventajas descritas hasta ahora son convincentes, existen, sin embargo, algunos desafíos técnicos que, a menudo, obstaculizan los proyectos de migración.

  • Movimiento de datos. Los conjuntos de datos que son procesados por los nodos de procesamiento de un clúster normalmente deben estar habilitados a etapa en la nube antes de ejecutar los trabajos. La administración del movimiento de datos puede ser compleja, según el volumen de los datos y cómo se administran. Las herramientas como Avere pueden ser útiles para esto, ya que proporcionan una capa de almacenamiento en caché en la nube que mueve de forma automática los datos cuando es necesario, pero en muchas apps los conjuntos de datos deben almacenarse en etapa intermedia de forma manual.

  • Acceso a los datos. Muchas aplicaciones de HPC requieren acceso compartido a un conjunto de archivos y directorios. La forma en que se proporciona este acceso puede afectar el rendimiento de la app de forma significativa. Puedes aprovechar los datos compartidos que se almacenan en Cloud Storage mediante servidores NFS, como FileStore, o mediante sistemas de archivos paralelos, como se explica en la sección Almacenamiento.

  • Seguridad. Para los datos confidenciales, debes asegurarte de que el acceso siempre esté autorizado y de que los datos estén correctamente encriptados en reposo y en tránsito. Mientras que Cloud Storage encripta los datos en reposo y en tránsito, puedes aplicar una capa adicional de control y administrar claves en Cloud Key Management Service o por tu cuenta. Las claves deben recuperarse o instalarse en los nodos de procesamiento antes de ejecutar el trabajo.

  • Latencia entre nodos. En apps de HPC vinculadas de forma estrecha, el rendimiento puede ser sensible a la latencia entre nodos entre los nodos del clúster. Debido a que Google Cloud proporciona nodos con tamaños de hasta 64 núcleos, puedes ejecutar trabajos paralelos de 64 vías sin desviar nodos. En la mayoría de los casos, los trabajos de alrededor de 1,000 núcleos o más pequeños se desempeñan bastante bien en el hardware de red no especializado.

  • Administración de licencias de software. Muchas apps comerciales requieren un servidor de licencias, que a veces se conoce como servidor de claves. Algunas aplicaciones vienen con un servidor de licencias incorporado o recomendado y otras pueden ser compatibles con las ofertas de servidores de licencias existentes. Algunos programadores de trabajos pueden ayudar con la administración de licencias y evitar que los trabajos se ejecuten hasta que haya una licencia disponible.

La computación técnica proporciona muchas herramientas y enfoques para diferentes circunstancias. Con tantas opciones, puede que te resulte difícil comenzar. Sin importar qué software de administración de clústeres y qué programador elegiste, hay una serie de prácticas recomendadas que puedes seguir cuando ejecutes en Google Cloud.

  • Aprovecha las VM interrumpibles siempre que sea posible. Las VM interrumpibles son como las máquinas virtuales normales en Compute Engine, pero tienen un precio de hasta un 80% menos que las VM normales, con la advertencia de que pueden reclamarse con poca antelación. Para cargas de trabajo de alta capacidad de procesamiento, los programadores de trabajos detectarán la pérdida del nodo, lo tratarán como una falla de nodo y reprogramarán cualquier tarea que se ejecute en ese nodo en un recurso diferente. Si bien cualquier trabajo realizado en esos nodos perdidos podría perderse, la probabilidad de pérdida de nodos es lo suficientemente baja como para que el precio más bajo valga la pena. La tasa de pérdida esperada es del 5% al 15%. Las VM interrumpibles se limitan a un máximo de 24 horas de uso antes de ser recuperadas.
  • Aprovecha el costo y el ancho de banda de Cloud Storage en lugar de ejecutar tu propio sistema de archivos paralelo. Cloud Storage proporciona una coherencia sólida y un rendimiento paralelo escalable con un bajo costo general. Si bien la latencia del primer byte es alta en aproximadamente 100 ms, las aplicaciones que pueden aprovechar Cloud Storage en lugar de ejecutar un servidor de archivos paralelo en Compute Engine son más rentables. El ancho de banda disponible entre Cloud Storage y los nodos de procesamiento es suficiente para muchas apps. Algunos clientes informaron un ancho de banda agregado y sostenido de más de 23 GB/s.
  • Compila un clúster de una sola aplicación o de un solo grupo. Los clústeres tradicionales se comparten entre múltiples usuarios, grupos y apps, lo que puede generar largos tiempos de espera para los trabajos y un uso ineficiente de los recursos por parte de las apps. En Google Cloud, considera crear varios clústeres para cada grupo o proyecto, y usar clústeres que estén optimizados para apps específicas que se ejecutan en ellos. Ya sea que ejecutes un clúster durante dos horas o dos clústeres durante una hora cada uno, el costo total es el mismo, pero, con el último patrón, se pueden reducir los tiempos de espera y mejorar el rendimiento de la app.

Si bien cada implementación es única, las siguientes secciones ofrecen algunas recomendaciones generales para tres casos comunes.

Investigador independiente que busca procesar sus datos

Los investigadores individuales generalmente buscan ejecutar su aplicación a través de sus datos y completarla lo más rápido posible. Pueden ser expertos en su app, pero no quieren ser expertos en administración o gestión de clústeres.

Si ejecutas cargas de trabajo de alta capacidad de procesamiento, puedes considerar usar la API de Pipelines de Cloud Life Sciences. La API de Pipelines requiere que coloques tu app en un contenedor de Docker y los archivos de entrada en un bucket de Cloud Storage. Una vez hecho esto, puedes usar la herramienta de línea de comandos de gcloud para iniciar la app en cada uno de los archivos del depósito de Cloud Storage. Puedes colocar los resultados en otro bucket de Cloud Storage.

Aquí hay un ejemplo de un comando de ejecución de una tarea que usa SAMtools para generar un archivo de índice BAM desde un archivo BAM de entrada:

gcloud alpha genomics pipelines run --pipeline_id [PIPELINE_ID] \
--logging gs://[YOUR_BUCKET/YOUR_DIRECTORY]/logs \
--inputs inputFile=gs://genomics-public-data/gatk-examples/example1/NA12878_chr22.bam \
--outputs outputFile=gs://[YOUR_BUCKET]/[YOUR_DIRECTORY]/output/NA12878_chr22.bam.bai

En el ejemplo anterior, se ilustra lo siguiente:

  • [PIPELINE_ID] representa el ID de tu aplicación en la API de Pipelines.
  • [YOUR_BUCKET] representa el nombre de tu depósito de Cloud Storage.
  • [YOUR_DIRECTORY] representa el nombre de tu directorio.

No hay clúster para aprovisionar o administrar. Las tareas se ejecutan hasta que se completan en una VM que aprovisiona y administra la API de Pipelines. Esto es rentable porque Compute Engine factura por segundo de uso.

Clúster de tamaño pequeño o mediano para un solo proyecto o equipo

En un proyecto o equipo, los miembros pueden tener acceso a un clúster ejecutado por un equipo central para usuarios de toda la empresa, o pueden tener acceso a recursos a gran escala en un centro HPC fuera del sitio. En ambas situaciones, los clústeres se administran de manera profesional y se accede a ellos mediante herramientas estándar. Por ejemplo, los usuarios pueden usar una conexión ssh para conectarse a un nodo principal y usar secuencias de comandos de submit de Grid Engine a fin de enviar trabajos para su ejecución.

Un enfoque de este equipo sería usar ElastiCluster para definir un entorno de clúster que sea similar a sus sistemas locales. Pueden personalizar el clúster si seleccionan el tipo de máquina de Compute Engine más adecuado para su app y personalizar las secuencias de comandos de inicio a fin de instalar las dependencias de software de la app. Los datos de entrada aún se pueden almacenar en etapa intermedia en Cloud Storage, y se puede instalar gcsfuse en los nodos de procesamiento para activar los datos de entrada.

Estos detalles se registran en el archivo de configuración de ElastiCluster y cuando se necesita el procesamiento, se activa un clúster mediante la herramienta de línea de comandos, por ejemplo:

% elasticluster start astrocluster1

El clúster, con el nombre astrocluster1 en el archivo de configuración, se aprovisiona y se configura tal como se especifica. Las definiciones en un archivo de configuración son flexibles y admiten diferentes tipos de nodos como nodos principales y de procesamiento, discos persistentes de Compute Engine para espacio temporal, VM interrumpibles a fin de reducir el costo de las cargas de trabajo de alta capacidad de procesamiento y GPU con el objetivo de lograr operaciones aceleradas. Un ejemplo de una configuración básica para un clúster basado en Slurm con 10 nodos de procesamiento y 1 nodo principal con máquinas virtuales de 32 núcleos basadas en CentOS se vería de la siguiente manera:

[cluster/astrocluster1]
 cloud=google
 login=google
 setup=ansible-slurm
 security_group=default
 image_id=centos-7-v20170327
 flavor=n1-standard-32
 frontend_nodes=1
 compute_nodes=10
 ssh_to=frontend
 boot_disk_size=50
 

Finalmente, cuando no se ejecutan más trabajos en el sistema, el clúster se puede finalizar:

% elasticluster stop astrocluster1

Para cargas de trabajo más grandes, puedes hacer lo siguiente:

  • Busca personalizar los tipos de máquinas de clúster para reducir aún más los costos.
  • Agrega un archivador paralelo externo para aumentar el rendimiento a gran escala.
  • Agrega capacidades de escalamiento automático para agregar y quitar nodos adicionales según la dimensión de la cola.

Centro de HPC que agrega capacidad de pico de actividad a los clústeres existentes

Los centros de HPC principales tienen una gran capacidad de procesamiento, pero debido a que muchos grupos los usan en toda la organización o empresa, los centros de HPC suelen tener un uso alto constante y tiempos de espera prolongados en la cola. Por lo general, cuando se los compra, se tiene en cuenta una capacidad de producción específica, y cuando se envían cargas de trabajo imprevistas a la combinación, pueden disminuir el progreso de manera notable.

En estas situaciones, puedes generar un pico de actividad en el entorno de Google Cloud si agregas nodos de procesamiento de forma temporal al clúster. El clúster se convierte en un híbrido con el nodo principal y algunos nodos de procesamiento de ejecución local, además de otros nodos de procesamiento que se ejecutan en Google Cloud. Los nodos adicionales se pueden liberar cuando las colas de trabajos se desvían.

Generar un pico de actividad en la nube es conveniente por las siguientes razones:

  • Mantiene un entorno de usuario coherente para el envío de trabajos y la administración. Los usuarios no saben o no les afecta si se agregan nodos adicionales.
  • Permite a los administradores de TI definir políticas sobre cuándo generar picos de actividad para controlar los costos.

El mayor desafío consiste en proporcionar un espacio de nombres de datos y archivos coherente para los trabajos de los usuarios en los nodos locales y de Google Cloud. Es posible que los nodos de Google Cloud no tengan acceso a los mismos sistemas de archivos internos que los nodos locales. Si ese es el caso, los trabajos que hacen referencia a estos archivos no se ejecutarán.

Si los nodos de Google Cloud están configurados con permisos de acceso a archivos internos, los trabajos se ejecutarán, pero es posible que no se realicen de la misma manera, y pueden crear un ancho de banda de red adicional, además de cargos de salida. Además, es posible que los trabajos paralelos que se dividen en los nodos locales y en la nube tampoco funcionen bien debido a la latencia adicional entre las diferentes partes de la app.

En trabajos de alta capacidad de procesamiento, el uso de HTCondor para generar picos de actividad en los recursos de la nube elude muchos de estos desafíos. HTCondor admite el aprovisionamiento dinámico mediante GlideInWMS. A medida que los trabajos se envían a una cola de trabajos, pueden activar nodos que se aprovisionan y se agregan al clúster. Cuando se agregan, el programador de Condor transfiere los archivos de entrada al nodo designado y usa esos nodos adicionales para ejecutar las tareas y desviar la cola.

Próximos pasos

Obtén más información sobre los casos prácticos de la computación en clústeres en Google Cloud:

Obtén más información sobre:

Comienza a usar tu clúster:

Ejemplos de proyectos en GitHub: