Implementación en Python del soporte para el software Yade en la plataforma EasyBuild

Texto completo

(1)Universidad Central “Marta Abreu” de Las Villas Facultad de Ingeniería Eléctrica Departamento de Telecomunicaciones y Electrónica. TRABAJO DE DIPLOMA Implementación en Python del soporte para el software Yade en la plataforma EasyBuild Autor: Javier Antonio Ruiz Bosch. Tutor: MSc. Miriel Martín Mesa. Santa Clara 2016 "Año 58 de la Revolución".

(2) Universidad Central “Marta Abreu” de Las Villas Facultad de Ingeniería Eléctrica Departamento de Telecomunicaciones y Electrónica. TRABAJO DE DIPLOMA Implementación en Python del soporte para el software Yade en la plataforma EasyBuild Autor: Javier Antonio Ruiz Bosch Email: [email protected]. Tutor: MSc. Miriel Martín Mesa Email: [email protected] Profesor Asistente, Dirección de Informatización. Santa Clara 2016 "Año 58 de la Revolución".

(3) Hago constar que el presente trabajo de diploma fue realizado en la Universidad Central “Marta Abreu” de Las Villas como parte de la culminación de estudios de la especialidad de Ingeniería en Telecomunicaciones y Electrónica, autorizando a que el mismo sea utilizado por la Institución, para los fines que estime conveniente, tanto de forma parcial como total y que además no podrá ser presentado en eventos, ni publicados sin autorización de la Universidad.. Firma del Autor Los abajo firmantes certificamos que el presente trabajo ha sido realizado según acuerdo de la dirección de nuestro centro y el mismo cumple con los requisitos que debe tener un trabajo de esta envergadura referido a la temática señalada.. Firma del Autor. Firma del Jefe de Departamento donde se defiende el trabajo. Firma del Responsable de Información Científico-Técnica.

(4) i. PENSAMIENTO. Nuestra mayor debilidad radica en renunciar. La forma más segura de tener éxito es siempre intentarlo una vez más. Thomas Edison..

(5) ii. DEDICATORIA. A mi papá Antonio Fileno Ruiz Juanes, la primera persona que me motivó al uso de software libre, por guiarme y siempre estar al tanto de mi formación profesional..

(6) iii. AGRADECIMIENTOS. A Dios, A mis padres, abuelos y hermano, por ser todo en mi vida, A mi novia Dunailys y su familia, por el gran apoyo que me dieron, A los trabajadores de la DIC de la UCLV, por permitirme contar con ellos para lo que me hiciera falta, A mi tutor Miriel Martín Mesa, por su dedicación. A Kenneth Hoste, líder del proyecto EasyBuild que me ayudo incondicionalmente en el desarrollo de la tarea práctica. Gracias a él todo fue posible. A mis amigos de San Juan de los Yeras y de la UCLV, por darme felicidad en los momentos más estresantes..

(7) iv. RESUMEN. El uso de EasyBuild como herramienta para la instalación de paquetes en un sistema HPC facilita y da fiabilidad al trabajo del personal administrativo. Por lo tanto la implementación del soporte necesario para tener disponible el software Yade en EasyBuild permite que todos los sistemas que son gestionados por esta herramienta sean capaces de instalar Yade de forma fácil y fiable. Por lo que con este trabajo además de contribuir a la comunidad de desarrollo de EasyBuild se satisface la petición de despliegue del software Yade en el HPC de la UCLV y en el de la UnB de Brasilia, además de la aplicación que puede tener en cualquier HPC del mundo que use EasyBuild..

(8) v TABLA DE CONTENIDOS. PENSAMIENTO .....................................................................................................................i DEDICATORIA .................................................................................................................... ii AGRADECIMIENTOS ........................................................................................................ iii RESUMEN ............................................................................................................................iv INTRODUCCIÓN .................................................................................................................. 1 Organización del informe ................................................................................................... 3 CAPÍTULO 1.. CLÚSTER Y HERRAMIENTAS PARA LA GESTIÓN DE PAQUETES 5. 1.1. El clúster................................................................................................................... 6. 1.1.1. ¿Qué es un clúster? ........................................................................................... 6. 1.1.2. Clasificación de los clústers .............................................................................. 7. 1.1.3. Componentes de un Clúster .............................................................................. 8. 1.1.4. Estructura de un Clúster .................................................................................. 10. 1.1.5. Computación distribuida y Clúster ................................................................. 11. 1.1.6. Aplicaciones.................................................................................................... 13. 1.1.7. Limitaciones.................................................................................................... 14. 1.2. Métodos de instalación de paquetes más comunes en ambientes HPC ................. 15. 1.2.1. Gestores de paquetes tradicionales y sistemas port ........................................ 16. 1.2.2. Sistemas meta-compiladores........................................................................... 17. 1.2.3. Entornos de módulos y RPATHs .................................................................... 17. 1.3. Gestores de paquetes modernos ............................................................................. 18. 1.3.1. Gestor de paquetes Nix ................................................................................... 18.

(9) vi 1.3.2. Gestor de paquetes Maali ................................................................................ 20. 1.3.3. Gestor de paquetes SWTools .......................................................................... 21. 1.3.4. Gestor de paquetes Smithy ............................................................................. 25. 1.3.5. Gestor de paquetes Spack ............................................................................... 26. 1.3.6. Gestor de paquetes EasyBuild ........................................................................ 29. 1.4. Elección del gestor de paquetes EasyBuild para sistemas HPC ............................ 33. CAPÍTULO 2.. ESTRUCTURA,. EASYBUILD. 35. 2.1. INSTALACIÓN. Y. CONFIGURACIÓN. DE. Estructura de EasyBuild ......................................................................................... 36. 2.1.1. Easyconfig ...................................................................................................... 37. 2.1.2. Easyblocks ...................................................................................................... 38. 2.1.3. Script, pruebas y herramientas ........................................................................ 40. 2.1.4. Compliador toolchain ..................................................................................... 40. 2.1.5. Procedimiento de instalación paso a paso....................................................... 42. 2.2. Instalación de EasyBuild a través de script bootstrap ............................................ 46. 2.2.1. Dependencias .................................................................................................. 46. 2.2.2. Procedimiento bootstrap ................................................................................. 48. 2.3. Configuración de EasyBuild y uso de la línea de comandos ................................. 49. 2.3.1. Vía archivo de configuración .......................................................................... 49. 2.3.2. Vía variables de entorno ................................................................................. 51. 2.3.3. Vía argumentos en la línea de comandos........................................................ 52. 2.3.4. Línea de comandos con EasyBuild ................................................................. 52. 2.4. Conclusiones .......................................................................................................... 53. CAPÍTULO 3. 3.1. SOPORTE PARA EL SOFTWARE YADE EN EASYBUILD ............. 55. Creación del soporte necesario para el software Yade........................................... 56.

(10) vii 3.1.1. Dependencias del Yade y selección del toolchain .......................................... 56. 3.1.2. Creación del archivo easyconfig Yade ........................................................... 60. 3.2. Inclusión del nuevo soporte en repositorio oficial de EasyBuild ........................... 64. 3.2.1. Integración a GitHub ...................................................................................... 65. 3.2.2. Resultados de las pruebas en Jenkins ............................................................. 68. 3.3. Lanzamiento de EasyBuild 2.8.0 con Yade 1.20.0 incluido, instalación y uso en el. HPC de la UCLV. ............................................................................................................. 70 3.4. Conclusiones del capítulo ...................................................................................... 73. CONCLUSIONES Y RECOMENDACIONES ................................................................... 74 Conclusiones ..................................................................................................................... 74 Recomendaciones ............................................................................................................. 75 REFERENCIAS BIBLIOGRÁFICAS ................................................................................. 76.

(11) INTRODUCCIÓN. 1. INTRODUCCIÓN. Junto con el desarrollo de la ciencia y la tecnología se va incrementando la complejidad de los nuevos descubrimientos y por ende la simulación de estos en las computadoras. Es por ello que se necesita de supercomputadoras o grupos de estas para hacer realizable cualquier tarea de simulación que en una computadora personal tardaría meses o sería imposible. Actualmente muchas de las investigaciones y proyectos de simulaciones que se realizan en diversas empresas, universidades e incluso cualquier otro centro de desarrollo requieren del uso de un sistema HPC (High Performance Computing) bien configurado y con todas las aplicaciones que los usuarios finales necesitan tener disponible. No siempre es suficiente contar con un personal bien calificado pues, en ocasiones, sin la utilización de las herramientas adecuadas el proceso de instalación se torna complicado. Esto se debe a que muchos de los paquetes de software científicos en un HPC no están disponibles en binarios al alcance de los gestores de paquetes integrados en los sistema operativos sino que solo existen en archivos fuentes y muchas veces a pesar de existir ciertos estándares en los procesos de compilación e instalación, muchos paquetes tiene sus propios procedimientos que requieren de un análisis previo antes de lograr instalarlos en el sistema. La instalación de diversos softwares para distintos usuarios en un HPC es una tarea tediosa, repetitiva, propensa a errores y que requiere de mucho tiempo de trabajo para los administradores, lo cual no sería así si se utiliza alguna de las herramientas modernas para la gestión de paquetes. Son muchas las que han emergido recientemente a raíz del auge de los sistemas HPC, dentro de las más conocidas se encuentra: Smithy, Nix, HashDist, Maali, SWTools y Easybuild, esta última es la alternativa que se propone en este trabajo por ser sobre todo una herramienta de software libre, por contar con más de 900 paquetes a los que brinda soporte para automatizar el proceso de instalación y también por tener de respaldo una.

(12) INTRODUCCIÓN. 2. fuerte comunidad de desarrollo compuesta por desarrolladores de distintos centros y regiones del mundo. La plataforma de gestión de paquetes EasyBuild es una herramienta en constante desarrollo que nace en la Universidad de Ghent, Bélgica, utilizada en varios centros como: el Súpercómputo de Jülich y en el Biocentro de Vienna [1]. Recientemente en nuestro país específicamente en la Universidad Central de Las Villas (UCLV) se gestiona la instalación de software en el HPC con el uso de esta herramienta. En el HPC de la UCLV fue necesaria la instalación del software Yade, debido a la necesidad de un grupo de investigadores. Yade es una plataforma de software libre para modelos numéricos discretos basado en métodos de elementos discretos [2]. Este software no contaba dentro de los paquetes que EasyBuild soportaba, por lo tanto se decidió con este trabajo realizar la implementación del soporte necesario para dicho software en la plataforma EasyBuild y así garantizar la facilidad y fiabilidad de instalación del software mencionado en cualquier HPC del mundo y por ende en el de la UCLV, además contribuir a la comunidad de desarrollo de EasyBuild. Por lo que se plantea como objetivo general: Objetivo general: Implementar el soporte para el software Yade en la plataforma EasyBuild. Para lograr desarrollar este objetivo se plantea los siguientes objetivos específicos: Objetivos específicos: . Explicar la estructura, proceso de instalación y uso de la línea de comandos de EasyBuild.. . Describir las dependencias, herramientas y procedimientos que se usan para la compilación e instalación del software Yade.. . Implementar los ficheros necesarios que den soporte a EasyBuild para la instalación del software Yade.. . Evaluar la implementación a través de las Pull Requests en el repositorio oficial de EasyBuild.. Con este proyecto se pretende contribuir al desarrollo de la plataforma basada en software libre EasyBuild por lo que desde ese punto de vista se apoya la independencia tecnológica.

(13) INTRODUCCIÓN. 3. del software propietario. De esta manera se contribuye con la política trazada por la dirección del país en esta esfera permitiendo un ahorro a la economía de la institución ya que no es necesario pagar por la licencia de los softwares empleados. Con la implementación del soporte para el software Yade, tanto los administradores como los propios usuarios serán capaces de instalar esta aplicación en sus sistemas sin estar propenso a prácticamente ningún tipo de error y con un mínimo de tiempo necesario. Con la ejecución de este proyecto se puede compilar e instalar el software Yade automáticamente por EasyBuild junto con todas sus dependencias, por lo que el sistema es optimizado para la arquitectura en la cual se ejecutará, no así si se instalara directamente desde los binarios. Los resultados de la investigación poseen una aplicación práctica y teórica de gran trascendencia para los que quieran incluirse en la comunidad de desarrollo de EasyBuild, también para especialistas, investigadores y administradores de redes en el centro o cualquier institución que posea una red de computadoras con un sistema HPC. Específicamente se pondrá en funcionamiento en el HPC de la UCLV y en el de la UnB de Brasilia. El proyecto se basa en soluciones Open Source y se consta con un equipo de trabajo y las condiciones necesarias para su desarrollo por parte de la Dirección de Informatización (DI) de la UCLV. Además, este trabajo forma parte de las actividades que se desarrollan en un proyecto de colaboración financiado por el Consejo de Universidades Flamencas de Bélgica (VLIR). Organización del informe En el capítulo 1 se habla de los sistemas HPC partiendo de una definición más general: el clúster. También se menciona los métodos y herramientas más comunes para la gestión de paquetes y posteriormente se describen los gestores de paquetes modernos más conocidos que se usan en los sistemas HPC. Después en el capítulo 2 se explica la estructura, proceso de instalación y uso de la línea de comandos de EasyBuild, aspectos que son necesarios para entender el funcionamiento de esta herramienta y para que los usuarios sean capaces de utilizar el nuevo soporte añadido..

(14) INTRODUCCIÓN. 4. Por último, en el capítulo 3 se muestran los resultados obtenidos, y también se utiliza la línea de comandos de EasyBuild para demostrar la facilidad de instalación del software Yade una vez agregado el soporte..

(15) CAPÍTULO 1. CLÚSTER Y HERRAMIENTAS PARA LA GESITÓN DE PAQUETES. 5. CAPÍTULO 1. CLÚSTER Y HERRAMIENTAS PARA LA GESTIÓN DE PAQUETES. En este capítulo se aborda las generalidades de un clúster de cómputo y también se analizan las herramientas más comunes para la administración de paquetes, partiendo desde los métodos comunes hasta los gestores de paquetes modernos. En el primer epígrafe se tratan los aspectos relacionados a los sistemas HPC partiendo de una definición más amplia: clúster. En este se describen temas como los tipos de clúster, su clasificación, estructura, aplicaciones y limitaciones. También se define, describe y ejemplifica el término de cálculo distribuido que es la síntesis de los sistemas HPC. En un segundo epígrafe se aborda lo relacionado a los métodos y herramientas más comunes para la instalación de paquetes en sistemas Linux, esto es un aspecto fundamental en el proceso de administración de un sistema HPC. Estos métodos tradicionales son muy utilizados por muchos administradores que aún no se encuentran familiarizados o desconocen del uso de los gestores de paquetes modernos abordados en el tercer epígrafe. Por lo tanto, aquí se trata lo referente a los gestores de paquetes tradicionales que vienen incluidos con el sistema operativo, también se mencionan algunos sistemas bien conocidos, los metacompiladores y por último se habla de los entornos de módulos y RPATHS En el tercer epígrafe se hace una descripción básica de los gestores de paquetes más conocidos: Nix, Maali, SWTools, Smithy, Spack y EasyBuild. Aquí se mencionan algunas de las características de estos sistemas, así como algunos aspectos relacionados con sus estructuras, para posteriormente en el cuarto epígrafe demostrar la selección del uso de EasyBuild..

(16) CAPÍTULO 1. CLÚSTER Y HERRAMIENTAS PARA LA GESITÓN DE PAQUETES. 1.1. 6. El clúster. La velocidad en computación no es solo una conveniencia. Las computadoras más rápidas nos permiten resolver problemas más grandes, encontrar soluciones con mayor rapidez, con mayor precisión, y con un costo menor. Todo esto se suma a una ventaja competitiva. En las ciencias, esto puede significar la diferencia entre ser el primero en publicar y no publicar; en la industria, puede determinar quién es primero en la oficina de patentes. Los clústeres tradicionales de alto rendimiento han demostrado su utilidad en una variedad de usos: desde predecir el clima hasta el diseño industrial, desde la dinámica molecular a la modelización astronómica. High Performance Computing (HPC) ha creado un nuevo enfoque de la ciencia, el modelamiento es ahora una alternativa viable y respetada a la experiencia tradicional y los enfoques teóricos [3]. 1.1.1. ¿Qué es un clúster?. Un clúster es un conjunto de computadoras individuales interconectadas a través de hardware y software especializado, donde aparentan al usuario un único sistema (Figura 1.1). El software juega un papel fundamental ya que solamente un conjunto de computadoras conectadas entre sí no califican como un clúster de cómputo, cada PC debe interactuar con las demás PC disponibles y trabajar en equipo para cumplir los mismos objetivos y lucir ante el usuario como un único sistema [4].. Figura 1.1. Representación de un clúster Beowulf [5]. La red de comunicaciones entre los nodos también juega un papel muy importante en la eficiencia del equipo. Un conmutador (switch) de red normal no es suficiente, se debe elegir.

(17) CAPÍTULO 1. CLÚSTER Y HERRAMIENTAS PARA LA GESITÓN DE PAQUETES. 7. un conmutador especializado considerando el gran volumen de datos y la velocidad con la que son requeridos. Existen conmutadores de alta velocidad de transmisión de datos tipo Infiniband pero son demasiados costos y su utilización puede limitar sustancialmente el poder de cómputo de un clúster. Es esencial realizar una buena selección del tipo de conmutador a utilizar a fin de garantizar un bajo tiempo de latencia (tiempo de espera al enviar datos de un nodo a otro) y capacidad de memoria intermedia para evitar congestionamiento y pérdida de datos. Una aplicación o programa diseñado para ejecutarse en un clúster se ejecuta en el nodo maestro, el sistema operativo y la librería de paralelización se encargan de ejecutar copias de este programa en los nodos esclavos del clúster. Todas estas instancias de la aplicación se ejecutan en paralelo y trabajan en conjunto enviándose datos para colaborar en el cálculo de la solución final [5]. 1.1.2. Clasificación de los clústers. El término clúster tiene diferentes connotaciones para diferentes grupos de personas, en base al uso que se le dé y a los servicios que ofrecen, determinan el significado del término para el grupo que lo utiliza. En base a sus características se pueden tener Clústeres de Alto Rendimiento (HPC – High Performance Computing), clústeres de Alta Disponibilidad (HA – High Availability) o clústeres de Alta Eficiencia (HT – High Throughput). Alto Rendimiento (HPC): Son clústeres en los cuales se ejecutan tareas que requieren de gran capacidad computacional, grandes cantidades de memoria, o ambos a la vez. Llevar a cabo estas tareas puede comprometer los recursos del clúster por largos períodos de tiempo. Alta Disponibilidad (HA): Son clústeres cuyo objetivo de diseño es el de proveer disponibilidad y confiabilidad. Estos clústeres tratan de brindar la máxima disponibilidad de los servicios que ofrecen. La confiabilidad se provee mediante software que detecta fallos y permite recuperarse frente a los mismos, mientras que en hardware se evita tener un único punto de fallos, o sea tener redundancia de equipos. Alta Eficiencia (HT): Son clústeres cuyo objetivo de diseño es el de ejecutar la mayor cantidad de tareas en el menor tiempo posible, siempre que exista independencia de datos entre las tareas individuales. En estos casos el retardo entre los nodos del clúster no es considerado un gran problema..

(18) CAPÍTULO 1. CLÚSTER Y HERRAMIENTAS PARA LA GESITÓN DE PAQUETES. 8. Los clústeres pueden también clasificar como clústeres de IT Comerciales (coincide con la clasificación Alta Disponibilidad, Alta eficiencia) y clústeres Científicos (coincide con la clasificación Alto Rendimiento). A pesar de las discrepancias a nivel de requerimientos de las aplicaciones, muchas de las características de las arquitecturas de hardware y software, que están por debajo de las aplicaciones en todos estos clústeres, son las mismas. Más aún, un clúster de determinado tipo, puede también presentar características de los otros [6]. Otras bibliografías incluyen la clasificación Balanceando Carga (Load Balancing - LB). La idea detrás de LB es proporcionar un mejor rendimiento mediante la división del trabajo entre varios ordenadores. El término "balanceando carga" significa diferentes cosas para diferentes personas. Un clúster de alto rendimiento utilizado para el cálculo científico y uno utilizado como un servidor web probablemente se acercan al término “balanceando carga” de manera completamente distinta. Cada aplicación tiene diferentes requerimientos críticos. En cierta medida, cualquier clúster puede proporcionar redundancia, escalabilidad y un alto rendimiento, independientemente de su clasificación. Desde que el balanceo de carga proporciona una gran disponibilidad, no es raro ver tanto balanceo de carga como alta disponibilidad en el mismo clúster [3]. 1.1.3. Componentes de un Clúster. En general, un clúster necesita de varios componentes de software y hardware para poder funcionar. A continuación, se describen los más esenciales. Nodos: Pueden ser simples computadoras, sistemas multiprocesador o estaciones de trabajo (Workstation). En informática, de forma muy general, un nodo es un punto de intersección o unión de varios elementos que confluyen en el mismo lugar. Bajo el contexto de clúster tenemos dos tipos de nodos, que son: . Nodos Dedicados: los nodos no disponen de teclado, mouse ni monitor y su uso está exclusivamente dedicado a realizar tareas relacionadas con el clúster.. . Nodos no dedicados: los nodos disponen de teclado, mouse y monitor y su uso no está exclusivamente dedicado a realizar tareas relacionadas con el clúster, el clúster hace uso de los ciclos de reloj que el usuario del computador no está utilizando para realizar sus tareas..

(19) CAPÍTULO 1. CLÚSTER Y HERRAMIENTAS PARA LA GESITÓN DE PAQUETES. 9. Almacenamiento: El almacenamiento puede consistir en una NAS (Network Attached Storage), una SAN (Storage Area Network), o almacenamiento interno en el servidor. El protocolo más comúnmente utilizado es NFS (Network File System), sistema de ficheros compartido entre servidor y los nodos. Sin embargo, existen sistemas de ficheros específicos para clústeres como Lustre CFS (Cluster File Systems) y PVFS2 (Parallel Virtual File System 2). Sistemas Operativos: Debe ser multiproceso, multiusuario. Otras características deseables son la facilidad de uso y acceso y permitir además múltiples procesos y usuarios. Conexiones de Red: Los nodos de un clúster pueden conectarse mediante una simple red Ethernet con placas comunes (adaptadores de red o NICs), o utilizarse tecnologías especiales de alta velocidad como Gigabit Ethernet, Myrinet, Infiniband, SCI, etc. Middleware: Es un software que generalmente actúa entre el sistema operativo y las aplicaciones con la finalidad de proveer a un clúster lo siguiente: . Una interfaz única de acceso al sistema, denominada SSI (Single System Image), la cual genera la sensación al usuario de que utiliza un único ordenador muy potente;. . Herramientas para la optimización y mantenimiento del sistema: migración de procesos, checkpoint restart (congelar uno o varios procesos, mudarlos de servidor y continuar su funcionamiento en el nuevo host), balanceo de carga, tolerancia a fallos, etc.;. . Escalabilidad: debe poder detectar automáticamente nuevos servidores conectados al clúster para proceder a su utilización.. Existen diversos tipos de middleware, como por ejemplo: MOSIX, OpenMOSIX, Condor, OpenSSL, etc. Protocolos de comunicación y servicios: Protocolos de comunicación usados comúnmente en las redes de computadoras Aplicaciones: Aplicaciones que ofrecen los servicios a los usuarios..

(20) CAPÍTULO 1. CLÚSTER Y HERRAMIENTAS PARA LA GESITÓN DE PAQUETES. 10. Ambientes de Programación Paralela: Los ambientes de programación paralela permiten implementar algoritmos que hagan uso de recursos compartidos: CPU (Central Processing Unit), memoria, datos y servicios [6]. 1.1.4. Estructura de un Clúster. El enfoque más simple es un clúster simétrico. Con un clúster simétrico (Figura 1.2) cada nodo puede funcionar como un ordenador individual. Esto es extremadamente sencillo de configurar. Solamente se crear una subred con las máquinas individuales (o simplemente agregar los equipos a una red existente) y se añade algún software específico de clúster que sea necesario. Es posible que se desee añadir un servidor o dos, dependiendo de las necesidades específicas, pero esto generalmente implica poco más que añadir algún software adicional para uno o dos de los nodos. En esta arquitectura cada máquina es independientemente utilizable.. Figura 1.2. Clúster simétrico [3]. Hay varias desventajas para un clúster simétrico. La gestión y la seguridad del clúster pueden ser más difíciles. La distribución de carga de trabajo puede llegar a ser un problema, por lo que es más difícil lograr un rendimiento óptimo. Para los clústeres dedicados, una arquitectura asimétrica es más común. En los clústeres asimétricos (Figura 1.3) un ordenador es el nodo principal o frontend, este sirve como una puerta de enlace entre el resto de los nodos y los usuarios. Los nodos restantes se dedican exclusivamente al clúster. Dado que todo el tráfico debe pasar a través del nodo principal, los clúster asimétricos tienden a proporcionar un alto nivel de seguridad. Si los nodos.

(21) CAPÍTULO 1. CLÚSTER Y HERRAMIENTAS PARA LA GESITÓN DE PAQUETES. 11. restantes son físicamente seguros y sus usuarios son de confianza, lo único que se necesita es asegurar el nodo principal.. Figura 1.3. Clúster asimétrico [3]. También existen otras estructuras que en cierta manera se derivan de esta, como por ejemplo usar un servidor de acceso (login) que comparte ciertos directorios con el master. La ventaja de esto es que los usuarios no tienen acceso directo al servidor master por lo que la seguridad es aún mayor [3]. 1.1.5. Computación distribuida y Clúster. A menudo el término “paralelo” se utiliza para describir los clústeres, pero es más correcto usar el término computación distribuida. Por lo general, el término computación paralela se refiere a conjuntos fuertemente acoplados de cálculos. La computación distribuida se utiliza generalmente para describir la computación que abarca varias máquinas o varias ubicaciones. Cuando varias piezas de datos se procesan simultáneamente en la misma CPU, esto podría llamarse un cálculo paralelo, pero no debería ser descrito como una computación distribuida. Varias CPU en un solo encapsulado pueden ser utilizadas para la computación paralela, pero no serían un ejemplo de computación distribuida. Cuando se habla de sistemas de computadoras, el término paralelo por lo general implica una colección homogénea de ordenadores, mientras que la computación distribuida normalmente implica un conjunto más heterogéneo. Los cálculos que se realizan de forma asíncrona son más propensos a ser llamados distribuidos que no paralelos. Claramente, los términos paralelos y distribuidos se encuentran en los extremos de un conjunto de posibles significados. En cualquier caso, dado los significados exactos dependen del contexto..

(22) CAPÍTULO 1. CLÚSTER Y HERRAMIENTAS PARA LA GESITÓN DE PAQUETES. 12. Desde que la computación en un clúster es justamente un tipo de computación distribuida, vale la pena mencionar brevemente las alternativas. La distinción principal entre los clústeres y otras formas de computación distribuida es el alcance de la red de interconexión y el grado de acoplamiento entre las máquinas individuales, las diferencias son a menudo los de grado de acoplamiento. Los clústeres son generalmente restringidos a equipos de la misma subred o LAN. Pero también existen las rejillas de computación (grid computing), este término se utiliza con frecuencia para describir equipos que trabajan juntos en una WAN o Internet. La idea detrás del término "grid" es invocar una comparación entre un clúster potente y un grid de cálculo. Un grid de cálculo es un conjunto de equipos que proporcionan potencia de computación como una mercancía. Esta es un área activa de investigación y ha recibido (merecidamente) una gran cantidad de atención por parte de la Fundación Nacional de Ciencia de Estados Unidos. Las diferencias más significativas entre la computación en clúster y computación de grid son que las gird suelen tener una escala mucho mayor, tienden a ser más asincrónicas, y tienen un mayor acceso, autorización, contabilidad, y preocupaciones de seguridad. Desde un punto de vista administrativo, si se construye una grid, es importante dedicar tiempo a las cuestiones relacionadas con la seguridad. La grid de cómputo tiene la capacidad de proporcionar considerablemente más potencia de cálculo que los clústeres individuales ya que una de estas puede combinar un gran número de clústeres. Computación peer-to-peer proporciona otro enfoque de la computación distribuida. De nuevo, esto es un término ambiguo, peer-to-peer puede referirse a que “comparten ciclos”, para la infraestructura de comunicaciones, o para los datos reales distribuidos a través de una WAN o Internet. Peer-to-peer “compartiendo ciclos” es mejor ejemplificado por el SETI@Home1, un proyecto para analizar los datos de radiotelescopios para detectar señales de inteligencia extraterrestre. Esto funciona debido a que voluntarios cargan el software en sus ordenadores conectados a Internet, para una PC casual o usuarios de Mac, el software se ve como un protector de pantalla, cuando el equipo está inactivo, el protector de pantalla se enciende y el equipo comienza el análisis de los datos, si el usuario empieza a usar el. 1. http://setiathome.ssl.berkeley.edu/.

(23) CAPÍTULO 1. CLÚSTER Y HERRAMIENTAS PARA LA GESITÓN DE PAQUETES. 13. ordenador, el protector de pantalla se cierra y se suspende el análisis de datos. Este enfoque ha servido como modelo para otras investigaciones, incluyendo el análisis de los datos de cáncer y SIDA. Redes de intercambio de archivos peer-to-peer son mejor ejemplificadas por tecnologías Napster, Gnutella, o Kazaa. Con algunos esquemas de intercambio de archivos peer-to-peer, los ciclos también se pueden proporcionar para los cálculos distribuidos. Es decir, con la firma y la instalación del software para algunos servicios que no necesariamente se están ejecutando en todo momento o lo que es lo mismo, pueden ofrecer ciclos de inactividad, se pueden utilizar para otros usos más allá de compartir archivos. Los usuarios deben asegurarse de leer la licencia antes de instalar el software si no desea que los equipos sean utilizados de esta manera. Otros autores en la taxonomía de computación distribuida incluyen clústeres federados y constelaciones. Clúster federados son clústeres de clústeres, mientras que las constelaciones son clústeres donde el número de CPU es mayor que el número de nodos. Un clúster de cuatro nodos de ordenadores SGI Altrix con 128 CPUs por nodo es una constelación [3]. 1.1.6. Aplicaciones. Clústeres en Aplicaciones Científicas: . Se suelen caracterizar por ser aplicaciones computacionalmente intensivas. . Sus necesidades de recursos son muy importantes en almacenamiento y especialmente memoria.. . Requieren nodos y sistemas dedicados, en entornos HPC y HTC.. . Suelen estar controlados los recursos por planificadores tipo Maui y gestores de recursos tipo PBS.. . Son en muchas ocasiones códigos legacy, difíciles de mantener, ya que los dominios de aplicación suelen ser difícilmente paralelizables.. . Ejemplos: Simulaciones (earth simulator), genómica computacional, predicción meteorológica, simulación de corrientes y vertidos en el mar, aplicaciones en química computacional..

(24) CAPÍTULO 1. CLÚSTER Y HERRAMIENTAS PARA LA GESITÓN DE PAQUETES. 14. Clústeres en Aplicaciones Empresariales: . Suelen ser aplicaciones no especialmente intensivas computacionalmente, pero que demandan alta disponibilidad y respuesta inmediata, con lo que los servicios se están ejecutando continuamente y no controlados por un sistema de colas. . Es usual que un sistema provea varios servicios. Una primera aproximación para realizar una distribución del trabajo es separar los servicios:  Un servidor web con la base de datos en un nodo, el contenedor EJB (Enterprise JavaBeans) en otro y el servidor de páginas web en otro constituye un claro ejemplo de distribución en el ámbito empresarial.  Otra aproximación es instalar una aplicación web en un clúster Squid como proxy caché, Apache/Tomcat como servidor web de aplicaciones web, memcached como caché de consultas a la base de datos y mySQL como base de datos. Estos servicios pueden estar replicados en varios nodos del clúster..  1.1.7. Ejemplos: flickr, wikipedia y google [6]. Limitaciones. A pesar que los clústeres tienen mucho que ofrecer, estos no son una panacea. Existe un límite en cuanto aumentaría la velocidad de cómputo cuando uno adiciona otra computadora. En una situación ideal, se podría esperar que el cálculo fuera dos veces más rápido en dos ordenadores iguales que en uno, pero por desgracia, este es el caso límite y solo se trataría de acercar a este lo más posible. Todo cálculo se puede dividir en bloques de código o instrucciones que se pueden clasificar en dos formas exclusivas. O bien un bloque de código puede ser paralelizado y compartido entre dos o más máquinas, o el código es esencialmente serial y las instrucciones deben ejecutarse en el orden en que se escriben en una sola máquina. Cualquier código que no pueda ser paralelizado no se beneficiará de cualquier procesador adicional que esté disponible. Hay varias razones por las que algunos bloques de código no pueden ser paralelizados y deben ser ejecutados en un orden específico. El ejemplo más evidente es el de I/O (programas de entradas y salidas), en el que el orden de las operaciones es típicamente determinado por la disponibilidad de datos de entradas y salidas. También si va a generar un informe al final.

(25) CAPÍTULO 1. CLÚSTER Y HERRAMIENTAS PARA LA GESITÓN DE PAQUETES. 15. de un programa, usted no querrá los caracteres o líneas de salida impresos al azar sino después que todo el programa ha sido ejecutado. Otra razón por la que algún código no puede ser paralelizado proviene de las dependencias de datos dentro del código. Si se utiliza el valor de x para calcular el valor de y, se tendrá que calcular x antes de calcular y. De lo contrario, no se sabrá qué valor se debe utilizar en el cálculo. Básicamente, para poder paralelizar dos instrucciones, ninguna puede depender de la otra. Es decir, el orden en el que las dos instrucciones finalizan no debe importar. Por lo tanto, cualquier programa puede ser visto como una serie de secciones alternas, secciones que pueden ser paralelizadas y ejecutadas de manera efectiva en diferentes máquinas intercaladas con secciones que si deben ejecutarse como están escritas y que efectivamente solo se pueden ejecutar en una sola máquina. Si un programa pasa la mayor parte de su tiempo en el código que es esencialmente en serie, el procesamiento en paralelo tendrá un valor limitado para este código. En este caso, es mejor usar un servidor con una rápida CPU que computadoras en paralelo [3]. 1.2. Métodos más comunes de instalación de paquetes en ambientes HPC. Un entorno HPC requiere de constante dedicación por parte del personal que lo administra. Dentro de las tareas que más desarrolla el administrador es la preparación del soporte adecuado para los usuarios, que no abarca mucho más de la instalación y actualización de los paquetes de aplicaciones requeridos por algún usuario final. Estos paquetes en muchas ocasiones solo están disponibles desde las fuentes, tal es el caso de muchas aplicaciones científicas, por lo que el proceso de instalación entre ellas es muy diverso y requiere de un previo análisis para hacerlo. En muchas ocasiones los administradores deben instalar estas aplicaciones utilizando las conocidas herramientas Autoconf, Automake usando scripts de configuración y los comandos make, make install [7]. También existen otras como cmake [8] encargada de configurar el proceso de instalación donde el instalador le pasa las opciones que el software permite. Estas no son las únicas vías de instalación manual, también otros paquetes fuentes Python son publicados juntos con un script Python (setup.py) para la instalación con las.

(26) CAPÍTULO 1. CLÚSTER Y HERRAMIENTAS PARA LA GESITÓN DE PAQUETES. 16. herramientas de Python (por ejemplo pip [9]). Otros proyectos como Qt se deben compilar con qmake [10] y así sucesivamente existen otras variantes y derivados de las mismas que el instalador debe conocer antes de instalar un paquete desde las fuentes. Es por esto la gran importancia que tiene usar una herramienta capaz de automatizar este trabajo o gran parte de él y así el administrador se liberaría de estudiar con detalles el proceso de instalación de un paquete determinado por lo que el ahorro en tiempo y la comodidad en el trabajo sería mucho mayor que hacer el proceso manualmente, además un sistema automatizado bien desarrollado es poco propenso a errores. 1.2.1. Gestores de paquetes tradicionales y sistemas port. Los gestores de paquetes automatizan el proceso de instalación de un software determinado en el sistema operativo. Estos son capases de resolver e instalar las dependencias necesarias para una aplicación específica. Muchas de las distribuciones de sistemas operativos traen integrado un gestor de paquetes, RPM, yum y APT [11-13] son de los más conocidos. El problema con estos sistemas de gestión de instalación de software es que están hechos para instalar paquetes de repositorios binarios, por lo que cada versión de distribución de sistema operativo presenta su propio repositorio binario compilado específicamente para él. Por lo tanto, cualquier software fuera de estos repositorios que solamente esté disponible en fuentes como es el caso de muchos software científicos queda fuera del alcance de estos gestores de paquetes. Por otra parte, estas herramientas asumen que cada paquete presenta una sola versión y también los directorios de instalación para las aplicaciones binarias están predeterminados y requieren de privilegios de root (administrador del sistema) ya que normalmente son directorios del sistema. Además, desde el punto de vista de hardware, los paquetes binarios no necesariamente están optimizados para el hardware específico de un sistema determinado. Otros sistemas llamados Port tales como Gentoo, BSD Ports, MacPorts, y Homebrew [1418] compilan paquetes desde las fuentes en vez de instalarlos desde los binarios. Muchos de estos sistemas padecen de las mismas cuestiones en cuanto a múltiples versiones como los gestores tradicionales. Aunque también algunos permiten instalar múltiples versiones en la misma carpeta [14, 19]..

(27) CAPÍTULO 1. CLÚSTER Y HERRAMIENTAS PARA LA GESITÓN DE PAQUETES. 1.2.2. 17. Sistemas meta-compiladores. Sistemas meta-compiladores como: Contractor, WAF y MixDown [20-22] están relacionados con los sistemas gestores de paquetes, pero solamente están enfocados en la compilación de un paquete específico con sus dependencias. MixDown, por ejemplo provee excelentes características para establecer las banderas (flags) en un compilador, pero estos sistemas en general no proveen capacidades para manejar grandes repositorios de paquetes o para el uso de varias versiones simultáneas [19]. 1.2.3. Entornos de módulos y RPATHs. Diversas versiones de software no solo se dificultan para ser compiladas e instaladas, también pueden existir problemas en la propia ejecución de la aplicación debido a la localización de sus dependencias. Si un ejecutable no determina la localización de cierta dependencia, este no funcionará, o peor aún si le es direccionado una dependencia errónea por equivocación, este podría funcionar incorrectamente en determinado momento. Los binarios estáticamente direccionados no presentan estos problemas, pero los sistemas operativos modernos hacen uso extensivo de direccionamiento dinámico. Por defecto, un ejecutable dinámico en la mayoría de los sistemas es configurado para buscar solo en los caminos de las bibliotecas del sistema como /lib, /usr/lib, y /usr/local/lib, si los binarios son instalados en otras localizaciones, entonces el usuario que ejecuta el programa típicamente debe añadir los caminos de las bibliotecas de dependencias en LD_LIBRARY_PATH (o una variable de entorno similar) a fin de que el ejecutable las pueda encontrar. Pero a menudo, el usuario no es la misma persona que instaló la librería, e incluso los usuarios avanzado pueden tener dificultades determinando cuáles caminos añadir. Mucho de los administradores de sistemas HPC solucionan estos problemas usando entornos de módulos (environment modules), que permite a los usuarios cargar “load” para utilizar y “unload” para no utilizar módulos que hacen referencia a las localizaciones necesarias de dependencias de una aplicación específica. Los entornos de módulos surgieron en 1991 y existen muchas implementaciones [23-27]. Uno no de los más avanzados de estos es Lmod [26, 27]. El paquete de software de módulos de entornos es una herramienta muy conocida en la comunidad HPC. A través de simples archivos de texto, referidos como módulos de entorno,.

(28) CAPÍTULO 1. CLÚSTER Y HERRAMIENTAS PARA LA GESITÓN DE PAQUETES. 18. ofrecen a los usuarios una interfaz fácil de usar para preparar su sesión de entorno para utilizar un paquete de software en particular. Módulos de entorno describen los cambios en el entorno de sesiones que son necesarios para que una pieza de software funcione correctamente y añaden a las variables de entorno PATH y LD_LIBRARY_PATH, tal que los binarios y bibliotecas compartidas quedan fácilmente disponibles. La alternativa a la configuración del entorno de cada usuario es insertar en tiempo de compilación los binarios instalados a las rutas de búsqueda de librerías. Cuando se hace de esta manera, la ruta de búsqueda se denomina RPATH. RPATHs y módulos de entorno no son mutuamente excluyentes. Los módulos se pueden seguir utilizando para establecer las variables que no están relacionados con la vinculación, como MANPATH y PATH. La adición de RPATHs asegura que los binarios se ejecutan correctamente, independientemente de que el módulo correcto este cargado [19]. 1.3 1.3.1. Gestores de paquetes modernos Gestor de paquetes Nix. Nix requiere de un almacén (store) donde contiene todos los softwares y librerías que instala y utiliza expresiones Nix (expressions) para realizar todos los pasos necesarios para instalar un paquete necesario en el almacén. Expresiones Nix son especificaciones declaradas que describen todos los aspectos para la compilación de un componente (software o librería), por ejemplo, obtener las fuentes, compilarlas, determinar los componentes del cuales depende y las restricciones impuestas a esas dependencias. Estas expresiones no son hechas en un lenguaje de programación específico si no que usan un simple lenguaje funcional con un conjunto de atributos, esto ofrece la ventaja de la flexibilidad. Los usuarios avanzados o administradores del sistema pueden adaptar las expresiones Nix para compilar una variante de un componente adaptado específicamente a sus necesidades. Por ejemplo, alguna funcionalidad requerida desactivada por defecto puede ser habilitada y las funcionalidades innecesarias se puede desactivar, también los componentes puede ser compilados con los parámetros de optimización específicos para el entorno de destino. Las características principales de Nix son:.

(29) CAPÍTULO 1. CLÚSTER Y HERRAMIENTAS PARA LA GESITÓN DE PAQUETES. . 19. Instalación simultánea de múltiples versiones y variantes (permite tener el mismo software en varias versiones disponibles al usuario). . Atómico upgrades y downgrades (Para realizar el proceso de actualización reproducible y más eficiente en un sistema distribuido, el despliegue y el proceso de actualización debe ser automático).. . Entornos de usuarios múltiples (permite al usuario tener disponible todas las aplicaciones o librerías que el necesite al mismo tiempo, la forma de hacerlo depende de la interfaz, en caso de usar la interfaz PATH utiliza una ubicación que sería homólogo de /usr/bin donde almacena enlaces simbólicos o scripts contenedores en caso de sistemas que no soporten enlaces.. . Dependencias seguras (Nix detecta automáticamente las dependencia requeridas para un componente determinado). . Despliegue completo (realiza todos los pasos para la instalación de un software a partir de sus fuentes). . Soporte desde binarios transparentes al usuario como una optimización al soporte desde fuentes (Nix procesa binarios). . Recolector de basura seguro (permite ejecutar periódicamente el recolector de basura para eliminar paquetes viejos, sin referencia alguna). . Gestión de paquetes multi-nivel (niveles de gestión de paquetes centralizada y local). . Portabilidad. Tanto el gestor de paquetes Nix como el sistema operativo (NixOS) soportan la instalación de forma arbitraria de muchas configuraciones de software. Como en la mayoría de los sistemas HPC, este instala cada paquete en un prefix (ubicación) único, que Nix lo determina por el hash del archivo del paquete y sus dependencias por lo que el resultado no tiene una convención de nombre legible por humanos [19, 28, 29]..

(30) CAPÍTULO 1. CLÚSTER Y HERRAMIENTAS PARA LA GESITÓN DE PAQUETES. 1.3.2. 20. Gestor de paquetes Maali. Para apoyar a una amplia y diversa comunidad de usuarios el centro de Pawsey Supercomputing (previamente conocido como iVEC) ha desarrollado la herramienta Maali, un sistema automatizado y ligero para la gestión de un conjunto diverso de aplicaciones y bibliotecas científicas en el HPC de su centro. Inicialmente, Maali era conocido como iVEC Build System y fue desarrollado en el 2012 para apoyar los sistemas de clúster Epic y Fornax. Desde un punto de vista operativo, estos sistemas fueron casi idénticos, ambos tenían un hardware similar (Qlogic InfiniBand y CPU Intel Xeon), aunque también Fornax contaba con GPU NVIDIA. Fornax antes de ser puesto en producción fue usado como banco de pruebas para tratar de desarrollar un sistema de despliegue de software más automatizado que el existente. El trabajo inicial sobre Fornax permitió entender y perfeccionar el proceso de instalación de software y ya por fin utilizando el IVEC Build System se logró reconstruir toda la paquetería de software tanto en Epic como en Fornax. IVEC Build System luego de varios refinamientos fue lo que se convirtió en Maali Maali en su núcleo es un conjunto de secuencias de comandos (scripts) BASH que están diseñados para permitir la automatización del proceso de Autoconf (configure, make y make install) comúnmente utilizado por muchas aplicaciones HPC. Maali trabaja a partir de un conjunto de archivos de configuración a nivel de sistema que define un conjunto de variables de entorno por defecto. Esto permite controlar varios aspectos de la instalación; tales como la ubicación del directorio de compilación predeterminado, el directorio de instalación, la ubicación del código fuente (paquete original para ser descargado y almacenado), el lugar de los archivos de registro, y los compiladores utilizados para configurar y compilar una aplicación. Existe un archivo de compilación Maali separado para cada aplicación que, entre otras cosas, define qué entorno(s) de programación Cray se van a utilizar, estos pueden ser por lo general una selección de PrgEnv-cray, PrgEnv en Intel, y PrgEnv-gnu. Una función clave de Maali es capturar que módulos dependientes son usados, así como las banderas (flags) de configuración y las optimizaciones del compilador que se seleccionan y utilizan para generar la aplicación. Maali determina, además, lo que se requiere en el archivo de módulo de una aplicación o de una librería y genera automáticamente un nuevo archivo de módulo. Maali.

(31) CAPÍTULO 1. CLÚSTER Y HERRAMIENTAS PARA LA GESITÓN DE PAQUETES. 21. también captura los archivos de registro de las salidas de configuración y compilación (logs) útiles como referencia y para la depuración. Más recientemente, Maali se ha modificado para manejar CMake y Python para los pasos de compilación. La herramienta Maali automatiza los siguientes pasos: 1. Descargar el software. 2. Descomprimir el software. 3. Compilar e instalar el software (configure, make y make instalar). 4. Crear un archivo de módulo. 5. Documentar el procedimiento [30]. 1.3.3. Gestor de paquetes SWTools. SWTools también es una "infraestructura para el manejo de software" que fue desarrollado por el Centro Nacional de Ciencias de la Computación (NCCS) y Oak Ridge National Lab (ORNL). Estructura de directorio En el diseño de la estructura de directorios para el sistema de gestión de software SWTools, presenta una estructura jerárquica que consiste en tener instalaciones de documentación y software individuales para cada máquina. En la raíz del sistema, se crea una única carpeta para cada la máquina. Un compromiso es hecho en relación con el tema de las carpetas para las máquinas que son casi idénticas en cuanto al uso y el hardware, los principales ejemplos de esto son los sistemas Cray XT4. En el momento de desarrollo de la herramienta NCCS tiene consta de varios sistemas Cray XT4, y debido a esto se elige crear un directorio único para todo el software y la documentación XT4 (este directorio se encuentra en lo que se llamaría nivel de máquina). Esto es, en un intento de encontrar la solución que equilibre la duplicación del trabajo y el riesgo de incompatibilidad entre todas las máquinas. Por lo tanto, todos los sistemas XT4 comparten ejecutables y software. La mayoría de las otras máquinas dentro del NCCS no comparten ningún software y usan únicamente los softwares que son compilados específicamente para ese sistema..

(32) CAPÍTULO 1. CLÚSTER Y HERRAMIENTAS PARA LA GESITÓN DE PAQUETES. 22. Dentro de cada directorio de máquina, hay una carpeta para cada aplicación que se instala en la máquina. Además, se tiene un directorio llamado modulefiles que también reside en este nivel. Este directorio se utiliza para almacenar módulos (para usar con la aplicación GNU Modules [31]) por cada elemento de software instalado. En este nivel de la estructura de directorios se usa solamente nombres genéricos, sin especificar versión. Por ejemplo, carpetas para python y szip, y no python2.5.1 o szip2.0. Dentro de cada carpeta de la aplicación (nivel de aplicación), hay una carpeta para cada versión de ese software. Cada carpeta de la versión se nombra utilizando el número de versión. En el caso de las aplicaciones versionadas de manera compleja (por ejemplo GAMESS que utiliza una combinación de fechas y números de versión), una versión de nomenclatura estándar en función de la aplicación es adoptada y utilizada a partir de entonces. Una carpeta para cada compilación del software se crea dentro del directorio de versión. Estos directorios de compilación se denominan utilizando el formato de nombre os_compiler[_options]. Por ejemplo, una compilación en Jaguar podría llamarse sles9.2_pgi7.0.7_i8, la primera abreviatura es para el sistema operativo, en este caso Suse Linux Enterprise Server 9.2. El segundo es la abreviatura para el compilador, que en este caso es el grupo Group Incorporated Portland de compiladores. La última abreviatura en este caso es i8, lo que significa que esta compilación se ha compilado con soporte de entero de ocho bytes. Archivos usados por SWTools Dentro de cada nivel del sistema de gestión de software hay varios archivos que son utilizados por el sistema para almacenar información y automatizar tareas. En primer nivel en el que existen estos archivos es el nivel de aplicación. Cada carpeta de la aplicación contiene una carpeta para cada versión de la aplicación instalada en la máquina. Además, hay cuatro archivos utilizados por la herramienta de software. El primer archivo, check4newver almacena una fecha. La fecha en el archivo es la fecha en que SWTools deben comprobar si hay una nueva versión del software. Por defecto, el sistema utiliza un lapso de tiempo de 90 días entre las comprobaciones de versión. Sin embargo, esto se puede modificar para cualquier período de tiempo que el instalador encuentre apropiado. El script swversion se ejecuta si es el momento de comprobar si hay una nueva versión..

(33) CAPÍTULO 1. CLÚSTER Y HERRAMIENTAS PARA LA GESITÓN DE PAQUETES. 23. Otro archivo es description. Este archivo es una descripción HTML de la aplicación y su uso. Utiliza etiquetas básicas estándar HTML, como <h1>, <h2>, <p> y <pre>. No se incorporan estilos en el archivo más allá de este nivel básico. La idea detrás de este archivo es que el instalador de la aplicación será muy probablemente la persona más calificada para escribir la documentación sobre la aplicación. El instalador es probablemente el más familiarizado con el paquete, y está sin duda familiarizado con cualquier idiosincrasia particular de las compilaciones en el sistema. Por lo tanto, es de esperar que habrá una sola fuente de documentación tanto la documentación del sistema local y también la documentación proporcionada en la web externa. El tercer archivo es el archivo support que se encuentra en cada directorio de la aplicación. Este archivo es utilizado por SWTools para documentar el nivel de soporte que el NCCS proporcionará a los usuarios finales para esta aplicación. Hay cuatro palabras clave válidas que pueden usarse en este archivo: nccs, vendor, nccs+vendor o unsupported. La palabra clave nccs implica que esta aplicación fue instalada por el NCCS y que es una aplicación con soporte. La palabra clave vendor implica que la aplicación se proporciona con el sistema y que el proveedor del sistema proporcionará soporte. nccs+vendor significa que tanto una versión proporcionada por el proveedor y proporcionada por el NCCS está instalada en el sistema. Por último, la palabra clave unsupported implica que el NCCS no proporcionará soporte para esta aplicación, esta se utiliza para paquetes no esenciales que a menudo están instalados. El cuarto archivo en el directorio de la aplicación es el archivo versions. El archivo de versiones como su nombre también indica es utilizado por SWTools para determinar la versión actual, en desarrollo y en desuso. En el nivel de versión no hay archivos especiales usados por SWTools, es simplemente una carpeta para cada compilación presente dentro de la carpeta versión. En el nivel de compilación hay siete archivos separados que son utilizados por SWTools. Los tres primeros archivos rebuild, relink y retest, todos sirven a un propósito similar, son scripts escritos por el instalador de la aplicación para realizar la acción que indica el nombre de cada uno. Por ejemplo, un script de re-compilación (rebuild) debe limpiar por completo cualquier instalación existente y luego compilar la aplicación de nuevo..

(34) CAPÍTULO 1. CLÚSTER Y HERRAMIENTAS PARA LA GESITÓN DE PAQUETES. 24. El siguiente archivo que se encuentra en el nivel de compilación es el archivo .owners, que es utilizado por el sistema para documentar que miembro del personal es actualmente responsable del mantenimiento de ese paquete. Este archivo se crea automáticamente cuando se instala la aplicación, con el nombre de usuario del instalador de valor inicial. El quinto de archivo utilizado por SWTools en el nivel de compilación es el archivo status. Esta es una pieza vital del sistema; que permite al personal NCCS saber si una aplicación está lista para ser usada y completamente operativa. El archivo de estado es creado por el script reset. El sexto archivo es build-notes y es utilizado por SWTools en el nivel de compilación. buildnotes no es un archivo obligatorio; es un lugar para los instaladores documentar pasos especiales que tengan que hacer al compilar esta aplicación. Por último, el archivo dependencies es utilizado por SWTools para documentar todas las dependencias que son necesarias para que la aplicación pueda ser compilada. Esta información se almacena para uso de referencia. La herramienta SWTools consta de varios scripts que hacen posible la realización de las tareas pertinentes a la gestión de paquetes, así como el trabajo en la estructura de directorios expuesta anteriormente. . swaddpackage y swaddbuild: son los scripts que facilitan el proceso de instalación de una nueva aplicación.. . swbuild, swlink, y swtest: desempeñan funciones similares. Cada uno de estos scripts ejecuta el apropiado script de compilación, swbuild ejecuta rebuild, swlink ejecuta relink. Ellos soportan un número de características avanzadas que hacen posible hacer operaciones significativas de manera fácil.. . swversion es una herramienta que es usada por el personal NCCS para proactivamente actualizar tantas aplicaciones como sea posible, usa el archivo .check4newver.. . swduplicate: es el script designado para automatizar el proceso de realizar las actualizaciones..

(35) CAPÍTULO 1. CLÚSTER Y HERRAMIENTAS PARA LA GESITÓN DE PAQUETES. . 25. swreport: todas las características de reporte de SWTools están encapsuladas dentro de swreport.. El gestor de software SWTools de NCCS ha sido una gran desafío a pesar de estar estructurado únicamente para los requerimientos presentes en el NCCS, aun así este puede servir de información para ser usado en otros centros u organizaciones con requerimientos similares [32, 33]. 1.3.4. Gestor de paquetes Smithy. Smithy es un seguimiento de SWTools, y también se ha desarrollado en el NCCS/ORNL. Es compatible con la infraestructura SWTools y por lo tanto puede ser utilizado como un reemplazo directo de este, pero también es compatible con un enfoque alternativo utilizando fórmulas basadas en el sistema de gestión de paquetes Homebrew para Mac OS X. Como tal, proporciona soporte funcional disponible para ser utilizado en estas fórmulas, y permite la reutilización de código a través de fórmulas. Smithy está disponible al público junto con la documentación detallada. La actividad de desarrollo se ha ralentizado significativamente desde septiembre del 2013, con cambios ocasionales que en su mayoría se centra en correcciones de errores. Smithy está diseñado para gestionar programas dentro de un entorno HPC Linux o Mac utilizando modulefiles para cargar software para el usuario en una Shell de comandos. Compilaciones de software se crean en Smithy con una serie de convenciones: . Todo está organizado en la arquitectura o directorios del sistema operativo, por ejemplo: redhat6 o SLES11.. . Los prefix (directorio de los paquetes) se definen por su nombre, versión, nombres de compilación.. . Los softwares se cargan en un Shell utilizando modulefiles.. . Las compilaciones son realizadas por las fórmulas o los scripts de compilación (build scripts) [34, 35]..

(36) CAPÍTULO 1. CLÚSTER Y HERRAMIENTAS PARA LA GESITÓN DE PAQUETES. 1.3.5. 26. Gestor de paquetes Spack. Spack es otro de los gestores de paquetes modernos que es considerado como una buena alternativa. Está escrito en Python, gracias a su flexibilidad ha tenido un creciente uso en HPC. Al igual que los sistemas anteriores, Spack es compatible con un número arbitrario de las instalaciones de software, y como Nix puede identificarlos con los hashes. A diferencia de cualquier sistema anterior, Spack proporciona un lenguaje conciso para especificar y administrar el espacio combinatorio de configuraciones de software de HPC. Spack ofrece las siguientes características únicas: 1. Paquetes componibles, explícitamente parametrizados por la versión, plataforma, compilador, las opciones y dependencias. 2. Una sintaxis novedosa de especificación recursiva para el grafo de dependencia y limitaciones, que ayuda en la gestión de la construcción del espacio de parámetros. 3. Dependencias versionadas virtuales para manejar versionadas, incompatible ABI interfaces como MPI. 4. Un nuevo proceso de concretización que traduce una especificación de compilación abstracta en una especificación de compilación completa y concreta. 5. Un entorno de compilación que utiliza contenedores de compilador para hacer cumplir la consistencia de compilación y simplificar la escritura de paquetes. Estructura de Spack En Spack, los packages son scripts de Python, estos son los que compilan los softwares. Cada packages es una clase que se hereda de la clase base Package, esta implementa la mayor parte del proceso de compilación, pero las subclases proporcionan sus propios métodos de instalación para manejar los detalles de los paquetes particulares. La subclase no tiene que gestionar la ubicación de la instalación. Más bien, Spack pasa al método de instalar un parámetro prefix donde contiene la ubicación. El implementador de un package debe asegurarse de que la función de instalación instale el paquete en prefix, y Spack asegura que el prefix se calcula de manera única para todas las configuraciones de un package. Para simplificar la implementación de pakcages aún más, Spack incorpora un lenguaje de dominio.

(37) CAPÍTULO 1. CLÚSTER Y HERRAMIENTAS PARA LA GESITÓN DE PAQUETES. 27. específico (DSL). El DSL proporciona directivas, como depends_on, version, patch y provides, que añade metadatos a la clase package. Spack llama spec (especificación) a una única configuración de compilación. Spack comunica las dependencias y parámetros con el package principal utilizando el argumento spec en el método de instalación. Spack resuelve las dependencias debido a los parámetros depen_on especificados en los packages y crea recursivamente un grafo acíclico que en caso que el usuario no use ningún spec en la línea de comando, el grafo será un grafo completo donde Spack tendrá libertad cuando compile el paquete en cuantos a especificaciones de compilación, versiones, entre otros. También los spec no solo pueden ser definidos por el usuario en la línea de comandos, un software determinado puede tener como dependencia un paquete de una versión específica, en estos casos el propio archivo package que da soporte a la aplicación debe contener en sus parámetros de dependencia la spec de la versión que necesita y así Spack instalará previamente el paquete correcto. En este, el grafo de dependencia es abstracto, ya que podría describir más de una configuración de software y por lo tanto Spack aún con este no sería capaz de instalar lo que el usuario exactamente quiere. Antes de que Spack compile un spec, se debe garantizar las siguientes condiciones: 1. En el grafo spec (grafo completo) ningún paquete de dependencia debe faltar; 2. En el grafo spec (grafo completo) ningún paquete debe ser virtual; 3. Todos los parámetros deben estar establecidos para todos los paquetes en el grafo. Si la spec cumple con estos criterios, entonces ya no sería abstracto sino concreto. La concretización es el componente central del proceso de compilación de Spack que le permite reducir una descripción abstracta sin restricciones a una compilación concreta. Eso Spack lo resuelve con un algoritmo de concretización. Entorno aislado Spack. establece. PATH,. PKG_CONFIG_PATH,. CMAKE_PREFIX_PATH,. y. LD_LIBRARY_PATH para incluir las dependencias de la compilación que realiza. Otros sistemas de compilación utilizan comúnmente estas variables para ubicar dependencias, y el establecimiento les ayuda a asegurar que se detectan las bibliotecas correctas..

(38) CAPÍTULO 1. CLÚSTER Y HERRAMIENTAS PARA LA GESITÓN DE PAQUETES. 28. Spack gestiona RPATHs y otras políticas de compilación con compiler wrappers (contenedores de compilador). En cada entorno aislado de instalación, Spack establece las variables de entorno CC, CXX, F77, y FC para apuntar a sus scripts de contenedores de compilador. Estas variables son usadas por la mayoría de los compiladores del sistema para seleccionar compiladores C, C++ y Fortran, por lo que normalmente son captadas de forma automática. Cuando se ejecuta, los contenedores insertan banderas include (-I), library (-L), y RPATH (-Wl, -rpath o similar) en la lista de argumentos. Estos apuntan a los directorios include y lib de las instalaciones de dependencia, donde se encuentran las headers (cabeceras) y bibliotecas necesarias. Los contenedores invocan el compilador real con los argumentos modificados. Esto causa que los contenedores de compilador de Spack incurran en una pequeña pero notable sobrecarga de rendimiento. Además de gestionar el entorno de tiempo de compilación, Spack puede ayudar en la gestión del entorno de tiempo de ejecución. Un paquete puede necesitar como variables de entorno PATH, MANPATH o PKG_CONFIG_PATH establecidas antes de que pueda ser utilizado. Muchos sitios se basan en módulos de entorno para configurar el entorno de tiempo de ejecución. Spack puede crear automáticamente simples dotkit [6] y los archivos de configuración del módulo para sus paquetes, lo que permite a los usuarios configurar su entorno de tiempo de ejecución utilizando sistemas conocidos. Mientras que los paquetes Spack no necesitan LD_LIBRARY_PATH para funcionar, se establecen en los archivos de los módulos generados, para que puedan ser utilizados por los sistemas de compilación para encontrar las bibliotecas, y también por los paquetes dependientes que no utilizan RPATH. Las futuras versiones de Spack también podrán permitir la creación de jerarquías Lmod [26]. Spack como filosofía gestiona muchas versiones diferentes de paquetes con facilidad, pero también proporciona un conjunto de referencias de extensiones sin necesidad de la configuración del entorno. Para apoyar este modo de operación, se añadió a Spack el concepto de paquetes de extensión. Módulos de Python utilizan la directiva extends(‘python’) en lugar de depends_on(‘python’). Cada módulo se instala en su propio prefijo de paquete como cualquier otro, y cada módulo depende de una instalación de Python en particular. Sin embargo, las extensiones pueden ser activadas o desactivadas dentro de la instalación de Python dependiente. La operación de activación vincula simbólicamente cada archivo en el prefix de extensión en el prefix de instalación de Python, como si este fuera instalado.