Consideraciones sobre datos y almacenamiento de clústers de HPC en la nube de AWS

Por Nina Vogl, Arquitecta especialista principal de HPC y

Jose Lorenzo Cuencar, Arquitecto Senior de Soluciones de AWS

Al diseñar un clúster de HPC en la nube o en cualquier otro lugar, los primeros pensamientos tienden a centrarse en la computación, el rendimiento, la interconexión, el ancho de banda de la red, etc. A menudo se pasan por alto las consideraciones de almacenamiento y los datos, incluidos, entre otros, los datos de entrada, los datos de salida y, por último, pero no menos importante, los archivos binarios de la aplicación. La consideración del almacenamiento contribuyen al rendimiento general de las aplicaciones (rendimiento de E/S), su arquitectura y diseño; si se les da una consideración especial; también puede contribuir a la facilidad de uso, la reutilización de la configuración del clúster, el acceso a los datos, el uso compartido de datos y la colaboración, por nombrar solo algunos beneficios.

En este blog, enumeraremos opciones diferentes, evaluando sus ventajas y desventajas considerando los diferentes tipos de datos. Los aspectos que consideraremos para la evaluación son: funcionalidad, rendimiento, reutilización, mantenerse al día con las actualizaciones, versiones futuras, costo, facilidad de uso e integración y seguridad, en el caso de la HPC híbrida.

Resolver este aspecto de los datos permite que las pruebas de concepto tengan éxito, así como pasar de las pruebas a nivel de PoC a crear clústers de HPC a nivel productivo, los cuales mantienen los costos bajos al ser efímeros, se gestionan fácilmente, se reproducen de forma automática y son flexibles para ajustarse a las demandas cambiantes.

Las cargas de trabajo de HPC se dividen en gran medida en dos categorías: cargas de trabajo paralelas poco acopladas y cargas de trabajo estrechamente acopladas con el requisito de comunicación de subprocesos. Esto último se aborda tradicionalmente con la creación de clústers de procesamiento. Esto puede ocurrir tanto en un centro de datos como en la nube. En la nube de AWS hay disponible una herramienta de administración y automatización de clústers de código abierto llamada AWS Parallel Cluster. Esta herramienta facilita la implementación y la administración de clústers de computación de alto rendimiento (HPC). Existen otros métodos o herramientas para implementar clústers y, como se mencionó anteriormente, hay cargas de trabajo de HPC que no requieren un acoplamiento estrecho de los nodos de procesamiento. En este blog, asumimos que los clústers de HPC se construyeron con AWS Parallel Cluster v2 o v3; sin embargo, la mayoría de las consideraciones de almacenamiento son universales y, por lo tanto, serán útiles.

Antes de enumerar y analizar una variedad de soluciones de almacenamiento y datos para clústers de HPC, definamos qué tipo de datos debemos tener en cuenta:

• Datos de entrada, como los datos del modelo para la simulación.
• Datos intermedios y/o temporales, como puntos de control para el reinicio y la recuperación.
• Datos de salida, los resultados de la simulación, almacenados para que puedan ser utilizados por la siguiente aplicación, descargarlos para su procesamiento posterior, visualizarlos directamente en la nube o archivarlos; y por último, pero no menos importante.
• Los binarios o el origen de la aplicación HPC, para varias aplicaciones diferentes y, posiblemente, diferentes versiones de la misma aplicación, así como bibliotecas y herramientas por requisitos.

Hay una variedad de soluciones de almacenamiento que ofrece AWS, desde almacenamiento en bloque (almacenamiento conectado a la red o almacenamiento local) hasta instantáneas y AMIs (Amazon Machine Image, imágenes de máquina de Amazon), sistemas de archivos, sistemas de archivos paralelos, almacenamiento de objetos, almacenamiento de archivos a largo plazo y mucho más. Analizaremos varias de estas opciones en lo que respecta al uso de HPC y analizaremos sus ventajas y posibles desventajas. En un clúster de HPC, es probable que utilice una combinación de varias de estas soluciones de almacenamiento. Este blog le ayudará a elegir la combinación más óptima para su caso de uso específico.

Volúmenes e instantáneas de EBS

Amazon Elastic Block Store (EBS) proporciona volúmenes de almacenamiento de bloques persistentes para su uso con instancias de Amazon EC2 en la nube de AWS, lo que ofrece un rendimiento coherente y de baja latencia, y se puede conectar al nodo principal de un clúster de HPC, integrarse en el sistema de archivos del nodo principal y compartirse con los nodos de procesamiento.

Los nodos principales y de procesamiento deben colocarse en un grupo de ubicación para obtener el mejor rendimiento de procesamiento, lo que también permite un rendimiento uniforme al compartir el volumen de EBS del nodo principal con los nodos de procesamiento. Al instalar aplicaciones y herramientas en un clúster, puede colocarlas en el sistema de archivos del volumen de EBS. Cuando la configuración cumpla con sus requisitos, puede tomar una instantánea del volumen de EBS y terminar el clúster o nodo principal. Al crear un clúster nuevo, se puede hacer referencia a la instantánea de EBS y todos los datos estarán disponibles de inmediato.

Esto permite la automatización y crear fácilmente clústers efímeros sin perder el trabajo de configuración invertido.

Los tipos de volúmenes de Amazon EBS ofrecen diferentes características de rendimiento, como los volúmenes de IOPS aprovisionadas (SSD) (i01) optimizados para IOPS, donde los clientes pueden aprovisionar previamente la E/S que necesitan, y los volúmenes HDD optimizados para el rendimiento (st1) que están diseñados para usarse con flujos de trabajo impulsados más por el rendimiento que IOPS» Esto permite elegir el volumen de EBS de acuerdo con las necesidades de su aplicación HPC. Las aplicaciones (LS-Dyna, HYCOM, por ejemplo) que escriben muchos datos intermedios, como los puntos de control, se benefician de los volúmenes de tipo io1/io2, mientras que los tipos gp2/gp3 permiten soluciones más sensibles a los costos para aplicaciones con necesidades de IOPS medianas (la mayoría de las aplicaciones de CFD).

La ventaja de colocar aplicaciones, requisitos previos y datos en los volúmenes de EBS es que no tiene que modificar el sistema operativo subyacente. Esto, permite actualizar fácilmente a versiones más nuevas y correcciones, sin afectar las instalaciones y los datos de la aplicación. A veces, durante las configuraciones, los experimentos pueden afectar la integridad y el rendimiento del sistema operativo. Cuando use un volumen de EBS adicional al EBS raiz, dispondrá de un nuevo sistema operativo en el siguiente clúster y, sin embargo, todos sus datos y aplicaciones se montarán en el sistema de archivos. También admite actualizaciones de clústers paralelos de AWS de forma más fácil y automática.

El uso de volúmenes e instantáneas de EBS es una buena forma de empezar con los PoC o experimentos iniciales. Para ver un ejemplo y explicaciones paso a paso, puede leer el siguiente blog de Palabos.

Al analizar los datos de entrada, salida y metadatos, podría crear varios volúmenes de EBS para separar los diferentes tipos de datos entre sí, así como las aplicaciones, las bibliotecas y otros requisitos previos. Desde la perspectiva de los datos, los datos de entrada, salida y metadatos suelen funcionar bien en los volúmenes de EBS y S3 se puede aprovechar para conservar los datos de salida.

Los anti-patrones para el uso de volúmenes de EBS podrían ser escenarios con un conjunto diverso de aplicaciones, posiblemente también diferentes versiones de las mismas aplicaciones y bibliotecas de requisitos previos para varios usuarios finales que requerirían mantener una gran cantidad de instantáneas de EBS, aplicaciones que deben instalarse en un ubicación particular en el sistema de archivos Linux, o requieren modificaciones del núcleo. Si la instalación de la aplicación requiere una modificación sustancial y un ajuste del sistema operativo, configuraciones del entorno donde no se pueden reproducir creando scripts, resultar más sencillo convertir las aplicaciones y los requisitos necesarios en una Imagen de Maquina de Amazon AMI (Amazon Machine Image).

Un anti-patrón relacionado con los datos sería que las aplicaciones escriban muchos datos para puntos de control/reinicio y recuperación y posiblemente requieran un alto nivel de IOPS. Tenga en cuenta también que el nodo principal comparte el volumen de EBS a través de NFS. EBS ofrece opciones para mejorar el rendimiento. También debe considerar el costo de esos volúmenes. Las soluciones alternativas que abordan algunos de estos problemas podrían ser un disco local en los nodos de procesamiento o un sistema de archivos paralelo optimizado para HPC, como FSx for Lustre.

Volúmenes de nodo de computación local/almacenamiento de instancias de EC2

Los discos locales, ya sea en el nodo principal o en cada nodo de procesamiento, pueden ser soluciones para aplicaciones particulares, que tienen alto volumen de cambios y escriben muchos metadatos, por ejemplo, como puntos de control para el reinicio y la recuperación. Aplicaciones como LS-Dyna, un paquete avanzado de software de simulación multi física de propósito general o HyCom (modelo oceánico de coordenadas híbridas) son ejemplos de aplicaciones con alto grado de cambios, que pueden beneficiarse de considerar un nodo principal especial, como las instancias i3en, con almacenamiento local ó nodos de cómputos con discos locales.

Por lo general, si experimenta una degradación basada en el cuello de botella de E/S en el rendimiento de la aplicación, es posible que desee considerar soluciones de almacenamiento local, RAID para discos locales, etc. Se trata de casos de uso muy especiales, aunque las soluciones que se describen aquí no son necesarias para la mayoría de las aplicaciones de HPC, ya que estos tipos de las soluciones agregan complejidad y costos.

AMIs personalizadas

Una forma de mantener la configuración de datos, aplicaciones y clústers es el uso de Imágenes de Maquina de Amazon (AMI, Amazon Machine Images), que permiten tomar instantáneas de todo el entorno de servidores virtuales y crear una imagen reutilizable del mismo, en función de la cual se pueden lanzar otros servidores virtuales o incluso un clúster completo. AWS Parallel Cluster permite utilizar los IDs de las AMI para crear un clúster basado en una AMI existente.

Desde la versión 3 de AWS Parallel Cluster se utiliza el servicio EC2 Image Builder, que admite más fácilmente el uso de AMI personalizadas. Para obtener información detallada, consulte la Guía del usuario de AWS Parallel Cluster.

Esta solución es útil cuando hay que realizar muchas modificaciones en el sistema operativo. Por ejemplo, si se deben instalar versiones muy específicas de requisitos previos, cuando los clústeres deben de tener tiempos de creación muy rápidos sin demoras adicionales debido a instalaciones adicionales, si se requieren ajustes y ajustes exhaustivos del sistema operativo, generalmente cuando los cambios y las instalaciones no se pueden programar fácilmente.

Si crea una AMI personalizada, debe repetir los pasos que utilizó para crear su AMI personalizada con cada nueva versión de AWS ParallelCluster. Se recomienda que revise primero la sección acciones de arranque personalizadas para determinar si las modificaciones que desea realizar se pueden crear scripts y compatible con futuras versiones de AWS ParallelCluster.

Un caso de uso para las AMI personalizadas serían los clústers con necesidad de escalar los nodos de procesamiento rápidamente, especialmente si la alternativa son scripts de arranque largos.

Sistemas de archivos

Los sistemas de archivos distribuidos son otra excelente forma de compartir datos y aplicaciones en un clúster de HPC. Debido a algunas de las necesidades muy específicas de las aplicaciones HPC analizadas anteriormente, también se han desarrollado sistemas de archivos paralelos. En esta sección analizaremos algunas de las opciones disponibles en la nube de AWS.

EFS

Amazon Elastic File System (Amazon EFS) es un sistema de archivos elástico sin servidor que permite configurar y olvidar que le permite compartir datos de archivos sin aprovisionar ni administrar el almacenamiento subyacente. Está diseñado para escalar a petabytes según demanda sin interrumpir las aplicaciones. Amazon EFS está diseñado para ofrecer alta disponibilidad y durabilidad al almacenar datos de forma redundante en varias AZ, EFS es un servicio regional. A pesar de que Amazon EFS tiene diferentes modos de rendimiento, diseñados para proporcionar un mayor rendimiento e IOPS, así como una latencia más baja, no está diseñado para ser un sistema de archivos paralelo (como Lustre, por ejemplo), lo que garantiza, por ejemplo, el acceso oportuno al mismo archivo desde varios rangos de MPI de una solicitud común en HPC. Sin embargo, Amazon EFS es adecuado, por ejemplo, para guardar archivos y directorios principales para los usuarios de HPC.

FSx para Lustre

Como se mencionó anteriormente, existen los sistemas de archivos paralelos, que abordan específicamente las necesidades de escalabilidad y rendimiento de las aplicaciones HPC estrechamente acopladas, donde varios rangos de MPI leen o escriben en el mismo archivo simultáneamente. Algunos sistemas de archivos paralelos de código abierto bien conocidos son Lustre y BeegFS. También hay varios sistemas de archivos paralelos con licencia comercial.

Al igual que en un centro de datos, todos estos sistemas de archivos paralelos también se pueden instalar en instancias de Amazon EC2 y, a ponerlos a disposición de un clúster de HPC. Sin embargo, la implementación, la optimización, el ajuste y el mantenimiento de estos sistemas de archivos son bastante complejos y requieren mucho trabajo, independientemente de la ubicación.

Por esta razón, Amazon desarrolló una versión administrada del sistema de archivos Lustre Filesystem de código abierto, llamada Amazon FSx para Lustre, que ofrece todos los beneficios de Lustre, sin los problemas de configuración y mantenimiento ni la necesidad de administrar los servicios que contienen el sistema de archivos. Además, Amazon FSx for Lustre integra Amazon S3, lo que permite cargar datos en S3 y, con esto, sincronizar el sistema de archivos FSx for Lustre con un bucket de S3. Para obtener más información, consulte la Guía del usuario de FSx for Lustre. así como el blog sobre la integración mejorada de S3. También vale la pena mencionar que FSx for Lustre también se integra completamente con AWS Parallel Cluster, lo que facilita aún más la configuración de clústers de HPC efímeros con sistemas de archivos paralelos incluidos, sin ningún esfuerzo adicional, mantenimiento o requisitos de ajuste. Amazon FSx for Lustre ofrece diferentes opciones de implementación, como scratch, persistente y persistente2, según sus necesidades y requisitos arquitectónicos.

El aprovechamiento de un sistema de archivos paralelo ofrece muchos beneficios, especialmente en las configuraciones de clústers de HPC con necesidades de grandes cantidades de datos, debido a la gran cantidad de datos de entrada/salida, el gran número de usuarios, el uso de varias aplicaciones, etc. Para configuraciones más pequeñas puede resultar más rentable utilizar volúmenes de EBS optimizados para E/S en el nodo principal o nodos principales optimizados para almacenamiento, como se describió anteriormente en este blog.

Consideraciones adicionales

Otras necesidades de almacenamiento que se deben tener en cuenta son el almacenamiento a largo plazo, la forma de transferir datos de los centros de datos existentes a AWS, así como la instalación y administración de aplicaciones en general. La discusión exhaustiva de los tres temas está fuera del alcance de este blog. Sin embargo, incluiremos algunas declaraciones generales, así como enlaces al material existente, ya que hay muchos servicios de AWS disponibles, algunos no exclusivos de HPC, que abordan estas necesidades.

Las necesidades de almacenamiento y archivado a largo plazo se pueden abordar fácilmente con Amazon S3, las clases de almacenamiento de Amazon S3 Glacier y la administración del ciclo de vida del almacenamiento, e integrarse bien con las arquitecturas de clústers de HPC, como se describe en este blog hasta ahora.

La entrada de datos/modelos se puede lograr de varias maneras: datos disponibles públicamente se pueden descargar directamente desde sus orígenes, por el contrario, los datos disponibles en sus instalaciones o en un centro de datos se pueden cargar en S3 mediante servicios como AWS Storage Gateway – Amazon S3 File Gateway, AWS DataSync o incluso se pueden realizar cargas manuales hacia Amazon S3 utilizando la CLI de AWS, la cual se puede programar y automatizar.

Las aplicaciones de HPC para pruebas de concepto tipos de implementación similares se pueden integrar en instantáneas de EBS, como se describió anteriormente en este blog y se demuestra aquí. Como alternativa, las aplicaciones se pueden incluir en las AMI de los clientes o se pueden poner a disposición mediante sistemas de archivos persistentes, todo lo descrito anteriormente. Sin embargo, para entornos grandes de tipo centro de investigación, hay muchas otras herramientas que se pueden aprovechar en la nube de AWS, por ejemplo: usar módulos de Linux combinados con herramientas como EasyBuild, usar administradores de paquetes de HPC como Spack o implementaciones automatizadas de repositorios de código, como Github, Gitlab o AWS Codedeploy, AWS Codebuild y AWS Codepipeline.

Hay talleres gratuitos en línea que demuestran el uso de Spack con AWS Parallel Cluster:
Tutorial de Spack sobre AWS ParallelCluster, Cómo usar Spack para crear una caché de compilación y usarla en ParallelCluster, ejemplos específicos de aplicaciones para aplicaciones meteorológicas y Gromacs. Además, AWS anunció recientemente la Spack Rolling Binary Cache alojada en AWS. Por último, pero no menos importante, puede crear su propia caché de compilación de Spack para usarla en un clúster de HPC implementado por AWS ParallelCluster.

Conclusión

En este blog, enumeramos distintas opciones de almacenamiento para usar con los clústers de HPC en AWS, analizamos sus ventajas y los anti patrones. La mayoría de las implementaciones de clústers de HPC utilizan una combinación de estas soluciones de almacenamiento. Este blog le brinda la información que necesita para decidir qué combinación de soluciones de almacenamiento de AWS se adapta mejor a sus necesidades y los diferentes tipos de datos, como datos de entrada, resultados, aplicaciones y archivos intermedios/temporales.

Sobre los autores

Nina Vogl es una Arquitecta Principal Especialista de Soluciones de HPC en Amazon Web Services en el Sector Público Mundial. Nina ha ayudado a muchos clientes de todo el mundo a ejecutar con éxito Pruebas de Concepto y Pruebas piloto de HPC en la nube.

José Cuencar ha trabajado en empresas de consultoría, sector de la construcción ,y logística, así como startups de comercialización de bienes y servicios, apoyando en la adopción de tecnologías en la nube en América Latina. Actualmente se desempeña como Arquitecto de Soluciones en Amazon Web Services para el Sector Educativo en México donde se especializa en Cómputo y Computo de Alto desempeño, apoya a la transformación digital de instituciones educativas en México.