Uso de clústeres para computación técnica a gran escala en la nube

Esta solución proporciona orientación para realizar computación técnica a gran escala en Google Cloud. Muchas aplicaciones de computación técnica requieren un gran número de nodos de cómputo individuales, conectados en un clúster y coordinando el cálculo y el acceso a los datos entre los nodos.

Los conceptos y tecnologías subyacentes a la computación en clúster se han desarrollado en las últimas décadas, y ahora están maduros y se han generalizado. Migrar el paquete de software a Google Cloud puede agregar algunas arrugas, pero también ofrece una serie de oportunidades para reducir los costes y aliviar los cuellos de botella existentes en los entornos informáticos de alto rendimiento de la actualidad. Esta guía proporciona una visión general de las tecnologías, los desafíos y el actual conjunto de soluciones para ejecutar clústeres informáticos en Google Cloud.

La computación en clúster agrega y coordina una colección de máquinas para trabajar juntas y resolver una tarea. Los clústeres suelen tener un solo nodo principal (a veces llamado nodo maestro), cierto número de nodos de cómputo y posiblemente algunos otros nodos especializados. El nodo principal es el cerebro del sistema y es responsable de:

• Registro de nodos informáticos en el sistema.
• Supervisión de los nodos.
• Asignar trabajos a nodos particulares.

Los usuarios envían trabajos, que se componen de muchas tareas, donde una tarea es la unidad básica de trabajo. Algunas aplicaciones requieren que todas las tareas de un trabajo se ejecuten de forma simultánea y permiten que las tareas se comuniquen para implementar un algoritmo paralelo;algunos trabajos tienen un conjunto complejo de dependencias de tareas, de modo que determinadas tareas deben ejecutarse antes que otras; y algunas tareas pueden requerir configuraciones de nodos particulares en términos de memoria, CPU u otro hardware en particular en el que ejecutarse. Las tareas son ejecutables que leen los datos de entrada del almacenamiento, procesan los datos para producir un resultado y, a continuación, 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 utiliza muchos nodos de trabajo, estrechamente acoplados y ejecutándose simultáneamente para lograr una tarea. Por lo general, estas máquinas necesitan una latencia de red baja para comunicarse eficazmente. Las aplicaciones de ejemplo en este espacio incluyen modelado meteorológico,dinámica de fluidos computacional (CFD), modelado de tensiones en ingeniería y diseño electrónico.

• Computación de alto rendimiento (HTC): un tipo de computación en el que las aplicaciones tienen varias tareas que se procesan de forma independiente sin necesidad de que los nodos informáticos individuales se comuniquen. A veces, estas cargas de trabajo se denominan cargas de trabajo en paralelo o por lotes embarazosamente. Los ejemplos típicos incluyen renderizado de medios, transcodificación, genómica y simulación y procesamiento de eventos de física de partículas. Si necesita procesar una gran cantidad de 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:

• Software de gestión de sistemas que aprovisiona y construye clústeres.
• Planificadores que orquestan la ejecución de trabajos.
• Aplicaciones de usuario final.

En las siguientes secciones se analiza el software de gestión del sistema y los planificadores.

Software de administración de sistemas

Puede ejecutar software de agrupación en clústeres directamente en el hardware básico, como con clústeres locales, o en entornos virtualizados, como con cloudenvironments. Orquestar múltiples nodos en un clúster a mano requiere mucho tiempo y es propenso a errores. Puede utilizar software especializado de administración de clústeres para aprovisionar y configurar varios nodos y recursos, en conjunto, de una manera individualizada y determinista.

El software open sourceElastiCluster de la Universidad de Zúrich proporciona un enfoque nativo de la nube para la gestión del clúster, con soporte para el aprovisionamiento de nodos, mediante el uso del motor de computación, y la configuración de nodos mediante el uso de un conjunto de libros de reproducción Ansibl. ElastiCluster aprovisiona los nodos e instala un paquete de software base, que incluye NFS para el servicio de archivos, administración de cuentas de usuario NIS y programador de tareas para ejecutar aplicaciones de usuario. ElastiCluster es compatible con una variedad de schedulers, y puede usarlo desde el primer momento o personalizarlo para satisfacer las necesidades de equipos pequeños y medianos.

Si utilizas otros sistemas de gestión de configuración para administrar clústeres de CPH, como Chef, Puppet o Terraform, puedes aprovechar esas inversiones a medida que migras a Google Cloud utilizando las herramientas y complementos disponibles.

Google Cloud proporciona servicios nativos para aprovisionar e implementar sistemas de software de múltiples nodos. Cloud Deployment Manager le permite aprovisionar un conjunto de recursos en la nube, incluidos Compute Engine, grupos de instancias gestionados por Compute Engine y Almacenamiento en la nube. El tutorial Htcondor muestra cómo usar Cloud Deployment Manager y grupos de instancias administradas para proporcionar y configurar un clúster.

Planificadores de trabajos

Una vez que el clúster está operativo, el software que administra la ejecución de tareas y la asignación de nodos se denomina planificador de trabajos (a veces denominado gestor de carga de trabajo o gestor de colas). A menudo, un administrador de clúster viene con un programador de trabajos incorporado. Los planificadores de trabajos proporcionan una variedad de capacidades para ayudar a gestionar trabajos y tareas, como:

• Soporte para prioridades de trabajo entre usuarios y grupos, lo que ayuda a proporcionar una programación de trabajos basada en políticas.
• Soporte para tareas fallidas haciendo cola y reprogramando tareas.
• Consideración de dependencias de tareas y necesidades de recursos para la asignación de tareas.
• Escalar el tamaño del clúster en función del número de trabajos en la cola.

Hay una variedad de administradores de carga de trabajo comerciales y de código abierto populares.Los ejemplos incluyen Ahtcondor de la Universidad de Wisconsin, Slurm de SchedMD,Univa Grid Engine y LSF Symphony de IBM. Cada uno tiene sus puntos fuertes.

HTCondor está construido con una filosofía de no compartir nada y se utiliza a través de recursos compartidos para programar trabajos de manera oportunista en recursos que de otro modo estarían locos. Proporciona su propio movimiento de datos y, por lo tanto, no requiere sistemas de archivos compartidos. Como resultado, HTCondor se escala a cientos de miles de núcleos y puede usarlo en múltiples zonas y regiones. HTCondor se ha utilizado para cargas de trabajo híbridas, donde el trabajo se comparte o divide entre sistemas locales y basados en la nube. Sin embargo, como su nombre lo indica, se centra en trabajos de alto rendimiento, no en trabajos paralelos estrechamente acoplados.

Slurm y Univa Grid Engine proporcionan un entorno de clúster de HPC más tradicional, compatible con aplicaciones paralelas de alto rendimiento y alto rendimiento. Ambos asumen un sistema de archivos compartido a través de los nodos, lo que elimina la necesidad de mover los datos. Ambos proporcionan un entorno de usuario cómodo y familiar para el desarrollo de aplicaciones, ya que a menudo son las mismas herramientas que se usan en las instalaciones.Estos programadores de trabajos tradicionales son suficientes para clústeres de tamaño pequeño a mediano,pero a medida que aumenta el tamaño del clúster, la carga en el servidor de archivos se convierte en el cuello de botella para el rendimiento. Los sistemas de archivos paralelos y distribuidos (consulte la siguiente sección) pueden ayudar con este problema cuando están a gran escala. De forma alternativa, cuando no se requiere acceso a archivos de baja latencia, puede aprovechar el almacenamiento en la nube, que proporciona acceso a objetos de forma paralela mediante la API o a través de gcsfuse,donde se requiere compatibilidad con Posix.

Por último, Google Cloud incluye un servicio sencillo para programar tareas basadas en un locker en Compute Engine para cargas de trabajo de alto rendimiento: la API de líneas de vida de Cloud Life Sciencesp.Este servicio requiere que descomponga el trabajo en tareas, administre dependencias entre tareas y administre el ciclo de vida de la tarea. El proyecto de código abierto Dsub proporciona una herramienta de línea de comandos para lanzar trabajos por lotes y es compatible con la API de Canalizaciones de Ciencias biológicas en la Nube.

Almacenamiento

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

Alternativamente, cuando no se requiere acceso a archivos de baja latencia, puede aprovechar el almacenamiento en la nube, que proporciona un acceso a objetos paralelo mediante la API o a través de gcsfuse, donde se requiere compatibilidad POSIX.

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

Hay muchas razones para ejecutar clústeres de cómputo en la nube:

• Tiempo de solución. Lanzar un clúster de calidad de producción en la nube toma solo unos minutos, desde un pequeño clúster de 10 nodos con cientos de núcleos disponibles, hasta clústeres a gran escala con cien mil o más núcleos. Por el contrario, la construcción de nuevos clústeres en las instalaciones puede tardar meses en comenzar a funcionar. Incluso cuando los clústeres locales están disponibles, por lo general tienen una alta utilización y largos tiempos de espera en cola, a veces horas o días, antes de que los trabajos se programen para ejecutarse. En su lugar, puede crear sus propios clústeres en la nube, usarlos para sus cargas de trabajo y finalizarlos cuando se complete el análisis.

• Menor costo total de propiedad. Google Cloud no solo reduce el tiempo para la solución,sino que también puede reducir el coste total por ejecución al aprovechar máquinas virtuales preferibles, descuentos por uso a largo plazo y escalado dinámico. Puede agregar nodos cuando los trabajos estén en cola y eliminarlos cuando no sea necesario.

• Apoyo a la colaboración. En muchas situaciones, el análisis de cómputo se desarrolla en colaboración con diferentes personas en múltiples organizaciones. Google Cloud proporciona herramientas de gestión de identidades y accesos a nivel de proyecto para permitir el acceso controlado a los datos y las herramientas analíticas. Los usuarios autorizados pueden acceder a las mismas aplicaciones, datos y clústeres para garantizar que todos estén en la misma página sin tener que copiar datos, administrar versiones o configuraciones de sincronizadores.

• Recursos a medida de las tareas. Debido a que el costo de un trabajo depende solo de las horas de núcleo totales, en lugar de las instancias de número, la ejecución de clústeres en la nube permite que cada equipo o grupo tenga su propio clúster dedicado. Este enfoque puede aliviar otro punto doloroso importante de desarrollar políticas en torno al uso de grupos múltiples. A continuación, puede personalizar cada clúster de nube dedicado para ajustarlo a la aplicación de destino. Los clústeres locales tienden a formar parte de un recurso único para todos, compartido entre los diversos grupos y aplicaciones. En un entorno de este tipo, las políticas para compartir entre los grupos tienden a ser complejas de establecer y mantener.

• Integración. Antes de poder ejecutar grandes trabajos de computación, los investigadores hacen un trabajo significativo para preparar los conjuntos de datos. Después de pasar a la nube, estos investigadores pueden aprovechar las herramientas de big data disponibles en la nube. Los resultados de los sistemas de cómputo también deben analizarse. Herramientas como la galería de imágenes y el Datalab pueden proporcionar ventajas significativas con respecto a las disponibles en sistemas locales.

Consideraciones arquitectónicas

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

• Movimiento de datos. Por lo general, los conjuntos de datos procesados por los códigos de computación de un clúster deben almacenarse en la nube antes de ejecutar los trabajos.La gestión del movimiento de datos puede ser compleja, dependiendo del volumen de los datos y de cómo se gestionan. Herramientas como Avere pueden ayudar al proporcionar una capa de almacenamiento en caché en la nube que mueve automáticamente los datos cuando es necesario, pero para muchas aplicaciones, los conjuntos de datos deben prepararse manualmente.

• Acceso a 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 significativamente al rendimiento de las aplicaciones. Puede aprovechar los datos compartidos almacenados en el almacenamiento en la nube, en servidores NFS como el almacén de archivos, o utilizando sistemas de archivos paralelos, como se explica en la sección Almacenamiento.

• Seguridad. En el caso de los datos confidenciales, debe asegurarse de que el acceso esté siempre autorizado y de que los datos estén encriptados adecuadamente en reposo y en tránsito. Mientras que el almacenamiento en la nube cifra los datos en reposo y en tránsito, puede aplicar una capa adicional de control y administrar claves,ya sea en el Servicio de Administración de claves en la Nube o por su cuenta. Las claves se deben recuperar o instalar en los códigos de computación antes de ejecutar el trabajo.

• Latencia entre nodos. Para aplicaciones de HPC estrechamente acopladas, el rendimiento puede ser sensible a la latencia entre nodos del clúster.Dado que Google Cloud proporciona nodos con tamaños de hasta 64 núcleos, puede ejecutar trabajos paralelos de 64 direcciones sin atravesar nodos. En la mayoría de los casos, los trabajos de alrededor de 1000 núcleos o más pequeños funcionan razonablemente bien en hardware de red no especializado.

• Gestión de licencias de software. Muchas aplicaciones comerciales requieren un servidor alicense, a veces conocido 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 planificadores de trabajos pueden ayudar con la administración de licencias y evitar que los trabajos se ejecuten hasta que haya una licencia disponible.

Arquitecturas recomendadas y mejores prácticas

La computación técnica proporciona muchas herramientas y enfoques para diferentes circunstancias. Con tantas opciones, es posible que le resulte difícil comenzar.Independientemente de la elección del software de gestión de clústeres y el planificador, hay un número de prácticas recomendadas que puede seguir cuando se ejecuta en Google Cloud.

• Aproveche las máquinas virtuales preferibles siempre que sea posible. Las VM preferibles son simplemente VM normalizadas en Compute Engine, pero tienen un precio hasta un 80% inferior al de las VM normalizadas, con la advertencia de que se pueden recuperar sin previo aviso.Para cargas de trabajo de alto rendimiento, los planificadores de trabajos detectan la pérdida del nodo y la tratan como un error de nodo y reprograman cualquier tarea que se ejecute en ese nodo en un recurso diferente. Si bien cualquier trabajo realizado en esos nodos perdidos puede 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 EVM anticipadas se limitan a un máximo de 24 horas de uso antes de ser recuperadas.
• Aproveche el costo y el ancho de banda del almacenamiento en la nube en lugar de ejecutar su propio sistema de archivos en paralelo. El almacenamiento en la nube proporciona una consistencia fuerte y un rendimiento paralelo escalable con un bajo costo general.Si bien la latencia de primer byte es alta, aproximadamente 100 ms, las aplicaciones que pueden recuperar el almacenamiento en la nube en lugar de ejecutar un servidor de archivos paralelo en el motor de computación son más rentables. El ancho de banda disponible entre el almacenamiento en la nube y los nodos de cómputo es suficiente para muchas aplicaciones, algunos clientes han informado de un ancho de banda agregado sostenido de más de 23 GB/s.
• Cree un clúster de una sola aplicación o un solo grupo. Los clústeres tradicionales se comparten entre varios usuarios, grupos y aplicaciones, lo que puede dar lugar a largos tiempos de espera para los trabajos y al uso ineficiente de los recursos por parte de las aplicaciones. En Google Cloud, considere la posibilidad de crear varios clústeres para cada grupo o proyecto y usar clústeres optimizados para aplicaciones concretas que se ejecuten en ellos. Ya sea que ejecute un clúster durante dos horas, o dos clústeres de una hora cada uno, el costo total es el mismo, pero este último patrón puede reducir los tiempos de espera de cola y mejorar el rendimiento de la aplicación.

Si bien cada implementación es única, las siguientes secciones proporcionan 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 el programa, pero no quieren ser expertos en administración o gestión de clústeres.

Si está ejecutando cargas de trabajo de alto rendimiento, puede considerar usar la API Cloud Life SciencesPipelines.La API de Canalizaciones requiere que coloque su aplicación en un contenedor de Docker y coloque sus archivos de entrada en un cubo de almacenamiento en la nube. Una vez hecho esto, puede usar la herramienta de línea de comandos gcloud para iniciar la aplicación contra cada uno de los archivos del bucket de almacenamiento en la nube. Puede colocar los resultados en otro cubo de almacenamiento en la nube.

Aquí hay un ejemplo de un comando para ejecutar una tarea que utiliza Samtools para generar un archivo de índice BAM a partir de un archivo BAM de entrada:

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

Donde

• representa el ID de la aplicación en la API de Canalizaciones.
• representa el nombre del bucket de almacenamiento en la nube.
• representa el nombre de su directorio.

No hay clúster que aprovisionar o administrar. Las tareas simplemente se ejecutan hasta su finalización en una máquina virtual aprovisionada y administrada por la API de Canalizaciones. Esto es rentable porque calcula las facturas del motor por segundo de uso.

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

En un proyecto o equipo, los miembros pueden tener acceso a un clúster gestionado por un equipo central para usuarios de toda su empresa, o pueden tener acceso a recursos de gran escala en un centro de HPC externo. En ambas situaciones, los clusters se gestionan profesionalmente y se accede a ellos utilizando herramientas estándar. Por ejemplo, los usuarios pueden usar ssh para conectarse a un nodo principal y usar scripts de Motor de cuadrículasubmit para enviar trabajos para su ejecución.

Un enfoque para un equipo de este tipo es usar ElastiCluster para definir un entorno de clúster que sea similar a sus sistemas locales. Pueden personalizar el clúster seleccionando el tipo de máquina de motor de cómputo que mejor se adapte a su aplicación, y personalizar los scripts de inicio para instalar las dependencias de software para su aplicación. Los datos de entrada pueden almacenarse en una nube por etapas y puede instalargcsfuse en los nodos de cómputo para montar los datos de entrada.

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

% elasticluster start astrocluster1

El clúster, nombrado en el archivo de configuración como astrocluster1, se suministra y se configura como se especifica. Las definiciones de un archivo de configuración son flexibles y admiten diferentes tipos de nodos para nodos head y compute,discos permanentes de Compute Engine para espacio en cero, máquinas virtuales preferibles para reducir el costo de cargas de trabajo de alto rendimiento y GPU para un funcionamiento acelerado. Un ejemplo de configuración de base para un clúster basado en Slurm con 10 nodos de cómputo y 1 nodo principal que utiliza máquinas virtuales de 32 núcleos basadas en CentOS sería el siguiente:

 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 

Por último, cuando no se ejecuten más trabajos en el sistema, puede detener el clúster:

% elasticluster stop astrocluster1

Para cargas de trabajo más grandes, puede:

• Busque personalizar los tipos de máquinas de clúster para reducir aún más los costos.
• Agregue un archivador paralelo externo para aumentar el rendimiento a escala.
• Agregue capacidades de escalado automático para agregar y eliminar nodos adicionales en función de la profundidad de la cola.

Centro de HPC agregar capacidad de ráfaga a clústeres existentes

Los centros centrales de HPC tienen una enorme capacidad de cómputo, pero debido a que son utilizados por muchos grupos en toda la empresa u organización, los centros de HPC tienden a tener una alta utilización constante y largos tiempos de espera en cola. Por lo general, se adquieren teniendo en cuenta una determinada capacidad de producción, y cuando se envían cargas de trabajo imprevistas a la mezcla, pueden ralentizar significativamente el progreso.

En estas situaciones, puede irrumpir en el entorno de Google Cloud añadiendo nodos informáticos temporalmente al clúster. El clúster se convierte en un híbrido,con el nodo principal y algunos nodos de cómputo que se ejecutan en las instalaciones, y otros nodos de cómputo que se ejecutan en Google Cloud. Una vez agotadas las colas de trabajo, se pueden liberar los nodos adicionales.

Irrumpir en la nube es conveniente por un par de razones:

• Mantiene un entorno de usuario consistente para la presentación y gestión de trabajos. Los usuarios no saben o no les importa si se agregan nodos adicionales.
• Permite a los administradores de TI definir políticas para cuándo explotar, con el fin de controlar los costes.

El mayor desafío es proporcionar un espacio de nombres de archivos y datos coherente para los trabajos de usuario en los nodos locales y de Google Cloud. Es posible que los nodos de la nube de Google no tengan acceso a los mismos sistemas de archivos internos que los nodos locales. En esta situación, los trabajos que hacen referencia a estos archivos no se ejecutarán.

Si los nodos de Google Cloud están configurados con permisos internos de acceso a archivos, los trabajos se ejecutarán, pero es posible que no funcionen de la misma manera y que creen cargos adicionales de ancho de banda de red y egresos. Además, los trabajos paralelos que se dividen en nodos locales y en la nube también podrían no funcionar bien con la latencia añadida entre las diferentes partes de la aplicación.

Para trabajos de alto rendimiento, el uso de HTCondor para irrumpir en los recursos en la nube evita muchos de estos desafíos. HTCondor admite el aprovisionamiento dinámico utilizando GLIDEINWMS.A medida que los trabajos se envían a la cola de trabajos a, pueden desencadenar nodos que se proporcionan y se agregan al clúster. Cuando se agregan, el planificador de cóndor transfiere los archivos de entrada al nodo designado y usa esos nodos adicionales para ejecutar las tareas y drenar la cola.

Más información sobre casos de uso de computación en clúster en Google Cloud:

• Google Cloud, HEPCloud y sondeando la naturaleza de la naturaleza
• 220,000 núcleos y contando: el profesor de matemáticas del MIT rompe el récord de trabajo de motor de cómputo más grande

Más información:

• Servidores de archivos en Compute Engine
• Documentación de Cloud Deployment Manager

Comience con su clúster:

• Procesamiento por lotes con Compute Engine Autoscaler
• Creación de un clúster HTCondor mediante plantillas de Administrador de implementación en la nube

Proyectos de ejemplo en GitHub:

• dsub ejemplo: Trabajos por lotes simples con Docker
• Ejemplo de ElastiCluster

• Ejemplos de API de canalizaciones

• Prueba otras funciones de Google Cloud por ti mismo. Echa un vistazo a nuestras editoriales.