Universidad Aut onoma Metropolitana Unidad Iztapalapa

Divisi on de Ciencias B asicas e Ingenier a Proyecto de Ingenier a en Electr onica en Computaci on

Implementaci on de un Grid
Autores: Isaac Carre no Santoyo Francisco Javier Cordero Ramos Dan Suriel Guti errez Flores Asesores: Manuel Aguilar Cornejo Luis Angel Alarc on Ramos Jos e Luis Quiroz Fabi an

2010

 Indice general

1. C omputo Grid (Grid Computing). 1.1. Introducci on. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2. Origines del c omputo grid. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3. Denici on de computo grid. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2. Introducci on a gLite 2.1. gLite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2. Origen de gLite. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3. Arquitectura de gLite. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.1. Servicios de seguridad. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.2. Servicios de informaci on y monitoreo. . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.3. Servicios de Administraci on de Trabajo. . . . . . . . . . . . . . . . . . . . . . . .

5 5 5 6 7 7 7 8 8 8 9

2.3.4. Servicios de Datos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.3.5. Servicios de Acceso. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.4. Despliegue de Servicios. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.5. Organizaci on Virtual (VO: Virtual Organization). . . . . . . . . . . . . . . . . . . . . . . 11 3. Seguridad en gLite. 12

3.1. Certicado Digital. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 3.2. Autoridad Certicadora (CA: Certication Authority). . . . . . . . . . . . . . . . . . . . 13 3.3. Autoridad Certicadora en gLite. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 4. Implementaci on de gnoMint. 16

4.1. Instalaci on de gnoMint. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 4.2. Crear una Autoridad Certicadora. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 4.3. Exportar Certicado de Autoridad Certicadora. . . . . . . . . . . . . . . . . . . . . . . 17 4.4. Archivos necesarios para instalar una Autoridad Certicadora en gLite. . . . . . . . . . . 17

 INDICE GENERAL

UAM - Iztapalapa

4.5. Crear Certicados de Host y de Usuario. . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 4.5.1. Firmar solicitudes de certicaci on. . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 4.5.2. Exportar Certicados y Llaves Privadas. . . . . . . . . . . . . . . . . . . . . . . . 21 5. Componentes de gLite. 23

5.1. Servicio de Membres a de la Organizaci on Virtual (VOMS). . . . . . . . . . . . . . . . . . 23 5.1.1. Procesos ejecut andose sobre el servicio VOMS. . . . . . . . . . . . . . . . . . . . . 23 5.1.2. Archivos importantes en el VOMS. . . . . . . . . . . . . . . . . . . . . . . . . . . 24 5.2. UI (User Interface). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 5.3. Elemento de Computo (CE: Computing Element). . . . . . . . . . . . . . . . . . . . . . . 27 5.3.1. CREAM CE (Ejecuci on y Administraci on de Recursos de C omputo). . . . . . . . 28 5.3.1.1. Procesos ejecut andose sobre un CREAM-CE. . . . . . . . . . . . . . . . 29 5.3.1.2. Ubicaci on de archivos log. . . . . . . . . . . . . . . . . . . . . . . . . . 31 5.4. Nodo Trabajador (WN: Worker Nodo). . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 5.5. Torque (Batch System). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 5.6. WMS (Workload Management System). . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

5.6.1. Componentes del WMS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 5.6.2. Fases del envi o de un job. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 5.6.3. Interacci on del WMS con otros servicios del middleware. . . . . . . . . . . . . . . 37 5.6.4. Seguridad en el WMS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 5.7. SE (Storage Element) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 5.8. BDII (Berkeley Database Information Index). . . . . . . . . . . . . . . . . . . . . . . . . 40 5.8.1. Terminolog a de LDAP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

5.9. L&B (Logging and Bookeping) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 5.9.1. Componente Logger. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 5.9.2. Componente Server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 5.9.3. Estados de transici on de un job. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 5.10. Lenguaje de Descripci on de Trabajo (JDL). . . . . . . . . . . . . . . . . . . . . . . . . . 47 5.11. Servicio NTP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

 INDICE GENERAL

UAM - Iztapalapa

5.12. Archivo users.conf. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 5.12.1. Cuentas ordinarias pool. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 5.12.2. Cuentas especiales pool. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 5.13. Archivo groups.conf. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 6. Instalaci on de los Servicios gLite. 53

6.1. Conguraci on del Servidor NTP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 6.2. Conguraci on de los clientes NTP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 6.3. Repositorio jpackage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 6.4. Instalaci on de Certicados de Host y de Usuario . . . . . . . . . . . . . . . . . . . . . . . 56 6.5. Instalaci on de glite-VOMS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 6.5.1. Conguraci on de glite-VOMS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 6.5.2. Importar un certicado de usuario al explorador web. . . . . . . . . . . . . . . . . 61 6.5.3. Agregar usuarios a la VO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

6.6. Instalaci on de glite-UI. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 6.6.1. Conguraci on de glite-UI. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 6.6.2. Creaci on de certicado proxy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 6.7. Instalaci on del WMS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 6.7.1. Conguraci on del WMS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 6.8. Instalaci on de glite-WN y glite-CREAM. . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 6.8.1. Conguraci on de glite-WN y glite-CREAM. . . . . . . . . . . . . . . . . . . . . . 72 6.9. Instalaci on de glite-LB y glite-BDII. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 6.9.1. Conguraci on de glite-LB y glite-BDII. . . . . . . . . . . . . . . . . . . . . . . . . 76 6.10. Instalaci on de glite-SE. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 6.10.1. Conguraci on de glite-SE. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 A. Instalaci on y conguraci on de Ubuntu. 82

A.0.2. Conguraci on de la red. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 A.0.3. Asignaci on del hostname. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

A.0.4. Archivo hosts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 3

 INDICE GENERAL

UAM - Iztapalapa

A.0.5. Archivo resolv.conf. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 A.0.6. Reinicio del servicio de red y comprobaci on de su funcionamiento. . . . . . . . . . 84 B. Instalaci on y conguraci on de Scientic Linux. 86

B.0.7. Conguraci on de la Red. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 B.0.8. Archivo hosts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 B.0.9. Archivo network. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 B.0.10. Archivo resolv.conf. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 B.0.11. Reinicio del servicio de red y comprobaci on de su funcionamiento. . . . . . . . . . 89 Conclusiones. Bibliograf a. 90 92

Cap tulo 1

C omputo Grid (Grid Computing).

1.1. Introducci on.

Actualmente es casi imposible pensar hacer cierto tipo de ciencia sin el uso de recurso de computo geogr acamente distribuido (lo que se conoce como e-ciencia), debido a que los problemas cient cos que se plantean llegan a ser muy complejos, el uso esta herramienta no solo facilita resolver estos problemas, sino que permite hacerlo de una manera m as r apida. Ya que la ciencia exige d a con d a m as capacidad de procesamiento y/o almacenamiento, han surgido nuevos paradigmas de computaci on que vienen a satisfacer estos requerimientos, siendo el Computo Grid uno de estos nuevos modelos. Algunos ejemplos en los que se puede observar la necesidad de una gran capacidad de computo se muestran a continuaci on: 1. F sica de altas energ as: Aceleradores de part culas estudio de choques y part culas subat omicas. El Gran Colisionador de Hadrones (LHC1 por sus siglas en ingl es) produce 15 Petabytes de datos al a no. 2. Geof sica: Alrededor de 100Gb de im agenes satelitales por d a. Clima (simulaci on/predicci on). 3. Biolog a Bioqu mica: Simulaci on de miles de drogas y sus interacciones con ciertas prote nas. Estudio del Genoma Humano ADN (3.000.000.000 o m as de pares de bases). Como podemos ver son muchos los campos en los que es necesario una gran capacidad de computo, para el ejemplo del LHC el reto no solo es donde guardar toda esa informaci on, tambi en lo es el c omo analizarla.

1.2.

Origines del c omputo grid.

El Computo Grid no ha surgido de manera espont anea, sino que fue evolucionando de ideas y proyectos hasta convertirse en lo que es hoy. El antecesor inmediato de la computaci on Grid fue
El LHC (Large Hadron Collider), es un acelerador y colisionador de part culas ubicado en la Organizaci on Europea para la Investigaci on Nuclear (CERN: Conseil Europ een pour la Recherche Nucl eaire, por sus siglas en fr ances), cerca de Ginebra, en la frontera franco-suiza.
1

1.3. Denici on de computo grid.

UAM - Iztapalapa

el Metacomputing, utilizado para describir los esfuerzos de conectar los centros de supercomputo de Estados Unidos en los 90s. En 1995 surgieron dos proyectos de gran importancia en el metacomputing, el FAFNER (Factoring via Network-Enabled Recursion) que aspiraba a factorizar n umeros muy grandes dividiendo y distribuyendo el problema, y el I-WAY (Information Wide Area Year) que buscaba enlazar supercomputadoras utilizando las redes existentes y el cual tuvo inuencia para el desarrollo del Proyecto Globus.. El concepto de C omputo Grid nace en septiembre de 1997 a partir de un taller denominado Construyendo una Grid Computacional en el Laboratorio Nacional Argonne. A ra z de esto, en 1998, Ian Foster (que ya hab a participado en el proyecto I-WAY) de Argonne National Laboratory, y Carl Kesselman, de la Universidad del Sur de California, publicaron The Grid: Blueprint for a New Computing Infrastructure (La Grid: Anteproyecto para una nueva Infraestructura Computacional), un libro que establece las bases del C omputo Grid.

1.3.

Denici on de computo grid.

Se puede denir el Computo Grid como un nuevo modelo en la Computaci on de Alto Rendimiento que provee la infraestructura necesaria para poder compartir o integrar recursos heterog eneos (computadoras de escritorio, cl uster de computadoras, supercomputadoras, sistemas de almacenamiento o incluso sensores y aplicaciones) y distribuidos geogr acamente de una forma transparente, esto signica que los usuarios no necesitan estar conscientes de la ubicaci on de los recursos de computo, solo tienen que presentar su solicitud de servicio en un nodo de entrada y le corresponde al sistema Grid ubicar y enviar el trabajo a los recursos disponibles que cumplan los requerimientos especicados. Seg un Ian Foster, una Grid es un sistema que: Coordina recursos que no est an sujetos a un control centralizado. Usa protocolos e interfaces est andar, abiertos y de prop osito general. Provee una excelente calidad de servicio. La Computaci on Grid no puede ser considerada como una tecnolog a revolucionaria, m as bien, ha evolucionado de las tecnolog as existentes, tales como la computaci on distribuida, servicios web, Internet, tecnolog as de criptograf a que prestan sus funciones de seguridad y de la tecnolog a de virtualizaci on, como podemos ver ninguna de estas es completamente nueva, han existido desde hace un tiempo y han estado sirviendo diversas necesidades, la tecnolog a Grid toma caracter sticas de estas para desarrollar un sistema capaz de proporcionar los recursos computacionales para resolver algunas tareas en espec co.

Cap tulo 2

Introducci on a gLite
2.1. gLite
gLite es el middleware de pr oxima generaci on para el computo grid. Nacido de la colaboraci on de m as de 80 personas en 12 diferentes centros de investigaci on acad emica e industrial como parte del proyecto EGEE1 , gLite proporciona un marco para la creaci on de aplicaciones grid aprovechando el poder de la computaci on distribuida y recursos de almacenamiento a trav es de la Internet. Los servicios de gLite son utilizados actualmente en m as de 250 Centros de Inform atica por un n umero mayor a 15,000 investigadores en Europa y en el resto del mundo (Taiw an, Am erica Latina, Estados Unidos, etc.), en proyectos como EELA E-Infrastructure shared between Europe and Latin America (actualmente llamado GISELA: Grid Iniciatives for E-science Virtual Communities in Europe and Latin America) en el cual est an involucrados los pa ses Europeos: Espa na, Italia y Portugal as como los pa ses Latinoamericanos: M exico, Cuba, Argentina, Brasil, Chile, Per u y Venezuela. gLite combina una capa intermedia b asica con una gama de servicios de mayor nivel, se distribuye bajo una licencia de c odigo abierto favorable para los negocios e integra componentes de los mejores proyectos middleware para c omputo grid, tales como Condor y Globus Toolkit, as como componentes 2 on optima de middleware, compatible desarrollados para el proyecto LCG . El resultado es una soluci con planicadores tales como PBS, Condor y LSF, al estar construido teniendo como objetivo la interoperabilidad y la provisi on de servicios fundamentales que ayuden para el desarrollo de aplicaciones Grid en todos los campos. En t erminos generales se puede denir a gLite como un middleware Grid Orientado a Servicio que provee la gesti on de c omputo paralelo, recursos de almacenamiento, seguridad, auditor a y servicios de informaci on.

2.2.

Origen de gLite.

En computaci on Grid, la capa que proporciona el middleware resulta un componente crucial. Para el proyecto EGEE, se decidi o que lo mejor ser a una aproximaci on en dos fases. Originalmente, el EGEE utilizaba una capa intermedia basada en los trabajos del proyecto Grid de Datos Europeo (EDG:
http://www.eu-egee.org/ - Enabling Grids for E-sciencE, proyecto nanciado por la Comisi on Europea cuyo objetivo es aprovechar los avances en tecnolog a grid y desarrollar una infraestructura grid que este disponible para los cient cos las 24 horas del d a. (Este proyecto ocialmente termin o el 30 de abril de 2010, la infraestructura de c omputo distribuido ahora ser a mantenida por la European Grid Infrastucture). 2 http://lcg.web.cern.ch/lcg/ - El Grid de Computaci on para el LHC, se inicio en el 2003 y tiene como objetivo integrar miles de ordenadoes alrededor del mundo para almacenar y analizar los datos de los experimentos del Gran Colisionador de Hadrones en el CERN.
1

2.3. Arquitectura de gLite.

UAM - Iztapalapa

European DataGrid) que evolucion o despu es al middleware LCG. Paralelamente, EGEE desarrollo y reestructuro pr acticamente la totalidad de esta capa intermedia convirti endola en una nueva soluci on. Despu es de las fases de prototipos en 2004 y 2005, la convergencia con la distribuci on de LCG-2 se alcanz o en mayo de 2006, cuando la versi on gLite 3.0 fue liberada y se convirti o en el middleware ocial del proyecto EGEE. gLite 3.1 fue liberado el 06/06/07 y esta soportado para plataformas i386 y x86 64 aunque no todos los servicios son compatibles con esta u ltima, puede ser instalado en Scientic Linux 4 y es la versi on m as utilizada actualmente. La versi on m as reciente de gLite es la 3.2 liberada el 23/03/2009, solo es compatible con sistemas operativos de 64 bits y puede ser instalada en Scientic Linux 5 (en teor a puede ser cualquier distribuci on basada en Red Hat 5) o Debian 4 en donde solo es posible instalar el servicio WN. Actualmente gLite 3.2 no cuenta con todos los servicios disponibles, aunque estos se ir an introduciendo progresivamente. Cabe aclarar que es posible instalar servicios de gLite 3.1 y 3.2 en una misma Grid.

2.3.

Arquitectura de gLite.

Los servicios de gLite se basan en una Arquitectura Orientada a Servicio que facilita la interoperabilidad entre los servicios Grid y que permite cumplir f acilmente con est andares pr oximos, 3 en se basan en estos principios. Se espera que estos servicios tales como los del OGSA , que tambi trabajen de manera coordinada para alcanzar los objetivos del usuario nal, sin embargo, tambi en se pueden implementar y utilizar de forma independiente, lo que hace posible su explotaci on en diferentes contextos. De manera general gLite se puede agrupar en cinco grupos de servicios de alto nivel, los cuales se describen a continuaci on.

2.3.1.

Servicios de seguridad.

Engloba los servicios de Autenticaci on, Autorizaci on y Auditor a, que permiten la identicaci on de entidades (usuarios, sistemas y servicios), a los cuales conceden o niegan el acceso a los servicios o recursos, y proveen informaci on para un an alisis posterior a acontecimientos relacionados con la seguridad. Tambi en proporcionan funcionalidad para la condencialidad de datos y un servicio de conectividad din amica, como lo puede ser un medio para que un sitio consiga controlar los patrones de acceso a la red de aplicaciones y servicios Grid.

2.3.2.

Servicios de informaci on y monitoreo.

Proveen un mecanismo para publicar y consultar informaci on y usar esto para prop ositos de monitoreo. El sistema de informaci on y monitoreo puede ser usado directamente para publicar informaci on relacionada a los recursos de una Grid. Los servicios m as especializados, tales como el
El Open Grid Services Architectura, representa una evoluci on hacia una arquitectura Grid basada en conceptos de servicios y tecnolog as Web .
3

2.3. Arquitectura de gLite.

UAM - Iztapalapa

Figura 2.1: Arquitectura de gLite. Servicio de Monitoreo de Trabajo y los servicios de Monitoreo de Rendimiento de Red, pueden ser construidos en un nivel superior en base a los b asicos.

2.3.3.

Servicios de Administraci on de Trabajo.

Los principales servicios relacionados con la administraci on/ejecuci on de trabajos son el Elemento de C omputo, el Sistema Manejador de Carga, Contabilidad, Procedencia de Trabajo y el Administrador de Paquetes. Aunque en los servicios relacionados con la administraci on de trabajos, la contabilidad es un caso especial, ya que debe de tomar en cuenta no s olo la parte de procesamiento, sino tambi en los recursos de almacenamiento y red. El elemento de computo (CE: Computing Element) proporciona la virtualizaci on de recursos de computo (colas batch de un cl uster, supercomputadoras o incluso de estaciones de trabajo solas). Proporciona informaci on sobre los recursos y ofrece una interfaz para presentar y manejar trabajos en el recurso. El sistema manejador de carga (WMS: Workload Management System) es un metaplanicador que programa trabajos en los CEs disponibles de acuerdo a las preferencias del usuario y otras pol ticas. Tambi en realiza un seguimiento de los trabajos que gestiona a trav es del servicio de Registro y Contabilidad (LB: Logging and Bookkeeping). El servicio procedencia de trabajo (JP: Job Provence) proporciona informaci on persistente en los trabajos ejecutados en la infraestructura Grid para inspecciones posteriores y posibles reejecuciones. 9

2.4. Despliegue de Servicios.

UAM - Iztapalapa

Por u ltimo, el servicio Administrador de Paquetes (PM: Package Manager) permite la implementaci on din amica de aplicaciones de software.

2.3.4.

Servicios de Datos.

Los tres principales grupos de servicios relacionados al acceso de datos y archivos son: el elemento de almacenamiento, los servicios de cat alogo (Catalog Services) y el movimiento de datos (Data Movement). El elemento de almacenamiento (SE: Storage Element) proporciona la virtualizaci on de un recurso de almacenamiento (el cual puede abarcar desde un servidor de disco hasta complejos sistemas jer arquicos de almacenamiento de cintas) al igual que el CE con los recursos computaciones. Los Servicios de Catalogo hacen un seguimiento de la localizaci on de los datos asi como de metadatos relevantes (como checksums y tama nos de archivos) y los Servicios de Movimiento de Datos permiten una administraci on eciente de las transferencias de datos entre los SEs. El acceso a los archivos es controlado por las Listas de Control de Acceso (ACLs: Access Control Lists). Los metadatos de aplicaciones espec cas no se almacenan en los servicios b asicos de gLite, sino en los cat alogos de metadatos de dichas aplicaciones.

2.3.5.

Servicios de Acceso.

Son los servicios que permiten utilizar los recursos de la Grid, para el caso de gLite existe la Interfaz de Usuario (UI: User Interface), que por medio de una cuenta y certicado de usuario permite enviar trabajos para su ejecuci on.

2.4.

Despliegue de Servicios.

Los servicios y componentes de gLite pueden ser instalados individualmente en computadoras dedicadas (nodos) o combinados de diversas maneras para satisfacer los requisitos del sitio (algunos componentes no son compatibles entre s , por lo que hay que tener cuidado al instalar m as de un servicio en un mismo nodo), entendiendo a un sitio como el conjunto de elementos de una misma instituci on que componen a una Grid o parte de una Grid. El sitio m as b asico en gLite consta de un Elemento de Computo con sus Nodos Trabajadores, es decir, es un sitio que cede sus recursos de c omputo para procesamiento, pero este sitio como tal no puede trabajar por s solo, por lo que es necesario que se una a otro u otros sitios que le proporcionen los dem as servicios. A partir de estos componentes b asicos los sitios pueden ser tan grandes como se quiera o como la cantidad de nodos disponibles lo permita, ya sea abarcando todos los servicios para ser completamente funcional de forma independiente o haciendo uso de unos cuantos servicios de otros sitios para completar o hacer m as grande una Grid. En la siguiente imagen se puede observar una implementaci on b asica de una grid con gLite.

10

2.5. Organizaci on Virtual (VO: Virtual Organization).

UAM - Iztapalapa

Figura 2.2: Sitio grid con gLite.

2.5.

Organizaci on Virtual (VO: Virtual Organization).

La Organizaci on Virtual (VO) es un concepto importante en gLite, ya que gracias a esto se hace posible el compartir los recursos en una Grid de manera ordenada. Una VO se dene como una colecci on din amica de individuos y/o instituciones regidos por normas que proporcionan un intercambio coordinado de recursos. En otras palabras, las VOs posibilitan la existencia de grupos de diversas organizaciones y/o individuos para compartir recursos computacionales en forma controlada, de tal manera que los miembros puedan colaborar para llegar a un objetivo com un. Basados en los conceptos de las VOs, hay tres t erminos que proporcionan antecedentes para la comprensi on de los sistemas grid, estos t erminos son: virtualizaci on, heterogeneidad y dinamismo. El primero de estos t erminos es la virtualizaci on, el cual se reere a la integraci on de sistemas geogr acamente distribuidos y heterog eneos, de aqu se desprende el segundo termino la heterogeneidad, cuando hablamos de VOs, puede implicar que estamos hablando de una entidad multi-institucional, las organizaciones que forman parte de una VO pueden tener diferentes recursos en t erminos de hardware, sistema operativo y ancho de banda de la red, por lo tanto, podemos decir que un VO es una colecci on de recursos heterog eneos. El tercer t ermino de importancia es el dinamismo, los individuos o instituciones pueden unirse o dejar una VO seg un sus necesidades o conveniencia, de manera que los recursos de una VO no siempre son los mismos ya que pueden aumentar o disminuir en cualquier momento, por lo que una VO es una entidad din amica.

11

Cap tulo 3

Seguridad en gLite.
Antes de que los recursos de una Grid basada en gLite puedan ser utilizados por un usuario, este debe unirse a una VO perteneciente a la Grid, para ello debe de leer y estar de acuerdo con las reglas de uso y condiciones adicionales que la VO incluya. Una vez que el registro se ha llevado a cabo, el usuario puede acceder a los recursos. La Grid Security Infrastructure (GSI) permite autenticaci on y comunicaci on segura en una red abierta, esta se basa en una clave p ublica encriptada, certicados X.509, y el protocolo de comunicaci on Secure Sockets Layer (SSL), con extensiones para single sign-on y delegaci on. Con el n de autenticarse para utilizar los recursos Grid, un usuario necesita tener un certicado digital X.509 expedido por una Autoridad Certicadora (CA: Certication Authority) reconocida como v alida para ese sitio Grid. La mayor a de los recursos Grid tambi en se emiten con certicados que los autentican ante usuarios y otros servicios. El certicado de usuario, cuya llave privada est a protegida por un password, se utiliza para generar y rmar un certicado temporal, denominado certicado proxy (o simplemente un proxy), que se usa para la autenticaci on real de los servicios Grid y no necesita un password. Puesto que el hecho de poseer un certicado proxy es una prueba de identidad, el archivo que lo contenga deber a ser legible s olo por el usuario. Un proxy tiene de manera predeterminada, un periodo de duraci on corto (por default de 12 horas) para reducir los riesgos de seguridad en caso de que sea robado. La autorizaci on de un usuario en un recurso Grid espec co se puede hacer de dos formas distintas. La primera es la m as simple, y depende del mecanismo grid-maple. El recurso Grid tiene un gridmaple local que mapea certicados de usuario a cuentas locales, cuando la solicitud de un servicio por parte de un usuario llega a un antri on, el subject del certicado de usuario (contenido en el proxy) se compara con el que aparece en el grid-maple local, para determinar a cu al cuenta local (si existe alguna) se mapea el certicado de usuario, y esta cuenta es luego utilizada para llevar a cabo la operaci on solicitada. La segunda forma se basa en el Servicio de Membrec a de la Organizaci on Virtual (VOMS) y el mecanismo LCAS/LCMAPS, que cuenta con una denici on m as detallada de los privilegios del usuario. Un usuario necesita un proxy v alido para enviar trabajos. Esos trabajos conservan sus propias copias del proxy para estar en capacidad de autenticarse con los servicios Grid mientras se ejecutan. Para trabajos de larga ejecuci on, el proxy del trabajo puede expirar antes de que el trabajo haya nalizado, causando la interrupci on del mismo. Para evitar que esto suceda, existe un mecanismo de renovaci on que mantiene al proxy del trabajo v alido tanto tiempo como sea necesario, el mecanismo que proporciona esa funcionalidad es el servidor MyProxy.

3.1.

Certicado Digital.

Un certicado digital es un documento emitido y rmado por una autoridad certicadora que garantiza que un sujeto o entidad es quien dice ser mediante su clave p ublica. Cada certicado est a identicado de manera u nica y tiene un periodo de validez se nalado en el propio certicado. En una 12

3.2. Autoridad Certicadora (CA: Certication Authority).

UAM - Iztapalapa

comunicaci on un certicado permite validar la identidad ya sea de una persona o dispositivo, siendo esto u ltimo importante en gLite, ya que tanto algunas m aquinas con servicios as como los usuarios necesitan certicados digitales. Existen diferentes formatos para un certicado digital, para la seguridad en gLite se utiliza el formato X.509, este tipo de certicado contiene la siguiente informaci on: Nombre Distintivo de la entidad: Incluye la informaci on de identicaci on (el nombre distintivo) y la llave p ublica. Nombre Distintivo de la Autoridad Certicadora: Identicaci on y rma de la Autoridad Certicadora (CA) que rm o el certicado. Per odo de Validez: El per odo de tiempo durante el cual el certicado es v alido. Informaci on adicional: Puede contener informaci on administrativa de la CA como un n umero de serie o versi on. El Nombre Distintivo de la entidad se usa para proveer una identidad en un contexto espec co de acuerdo a las necesidades de la aplicaci on. Los Nombres Distintivos est an denidos en el est andar X.509, as como por las necesidades de la aplicaci on, a continuaci on se denen los campos del nombre distintivo de la entidad: Nombre Com un (CN): Nombre (host o usuario) a ser certicado. Organizaci on o Compa n a (O): Nombre asociado con la Organizaci on. Ciudad/Localidad (L): Ciudad donde est a localizado el CN. Estado/Provincia (ST): Estado donde est a localizado el CN. Pa s (C): Pa s donde est a localizado CN.

3.2.

Autoridad Certicadora (CA: Certication Authority).

Una Autoridad Certicadora es una entidad de conanza encargada de emitir y/o conrmar certicados digitales, tambi en se encarga de administrar estos certicados, lo que incluye tener un control de cuales, cuantos y a quienes se le han expedido certicados, adem as de revocar certicados por un mal uso o por otras cuestiones de seguridad y publicar una lista de estos para que en una comunicaci on se conozca cuales ya no son validos. Una Autoridad Certicadora puede denir las pol ticas especicando cu ales campos del Nombre Distintivo son opcionales y cu ales requeridos. A continuaci on se muestra la interacci on entre equipos que utilizan certicados digitales basados en X.509. Cada transacci on hecha en la Grid es autenticada en forma mutua de la siguiente manera: 13

3.3. Autoridad Certicadora en gLite.

UAM - Iztapalapa

Figura 3.1: Certicaci on en gLite. 1. El Usuario 1 hace una petici on al Usuario 2. e su certicado. 2. El Usuario 2 solicita al Usuario 1 que envi 3. El Usuario 1 env a su certicado. 4. El Usuario 2 verica la rma en el certicado con la Autoridad Certicadora. a al Usuario 1 una frase aleatoria. 5. El Usuario 2 env 6. El Usuario 1 encripta la frase con su llave privada. a la frase encriptada al Usuario 2 7. El Usuario 1 env 8. El Usuario 2 usa la llave p ublica del Usuario 1 para descifrar la frase. 9. El Usuario 2 compara la frase descifrada con la original. 10. Si son la misma frase, el Usuario 2 verico adecuadamente la identidad del Usuario 1

3.3.

Autoridad Certicadora en gLite.

Para gLite existen diferentes Autoridades Certicadoras a las cuales se les puede solicitar certicados digitales para los servicios y usuarios, pero para este proyecto se implement o una Autoridad Certicadora propia. Para nuestra Autoridad se contemplaron dos posibilidades; una fue OpenCA, que es una herramienta que proporciona una interfaz Web que permite administrar la infraestructura de Clave P ublica, es decir, nos da la posibilidad de administrar los certicados digitales, pero debido a la 14

3.3. Autoridad Certicadora en gLite.

UAM - Iztapalapa

compatibilidad con la versi on del sistema operativo utilizado en un principio asi como a la dicultad para su instalaci on se busco otra opci on, siendo gnoMint el software que al nal se utiliz o para crear y administrar nuestros certicados. gnoMint es una herramienta para la f acil gesti on y administraci on de una o varias autoridades certicadoras X.509. Permite la creaci on de certicados para cualquier nalidad: rma o cifrado de correo electr onico, autenticaci on o cifrado mediante SSL o TLS a trav es de web, VPNs o cualquier otro protocolo.

15

Cap tulo 4

Implementaci on de gnoMint.
A continuaci on se describir a el proceso que se realizo para la implementaci on de gnoMint. El sistema operativo utilizado fue Ubuntu 9.10 (en el Ap endice se describen los pasos para la instalaci on de este sistema operativo) debido a que es posible hacer la instalaci on de gnoMint desde sus repositorios lo cual hace que el proceso sea relativamente sencillo.

4.1.

Instalaci on de gnoMint.

Ya que los paquetes de gnoMint se encuentra en los repositorios principales de Ubuntu, la instalaci on se realiza por medio de su gestor de paquetes de la siguiente manera: [root@host]$ apt-get install gnomint De esta forma se instalar a el paquete gnoMint as como las dependencias que sean necesarias. Una vez instalado gnoMint, podemos abrirlo desde el Menu principal de Ubuntu en la pesta na de Aplicaciones Herramientas del sistema gnoMint. Gestor de ACs X.509. La primera vez que se abre el programa, la ventana que se muestra se puede observar en la gura 4.1

Figura 4.1: Ventana inicial de gnoMint. A continuaci on se muestran los pasos para crear una Autoridad Certicadora, los Certicados de Host y los Certicados de Usuario.

4.2.

Crear una Autoridad Certicadora.

Seleccionamos Certicados A nadir A nadir autoridad de certicaci on auto-rmada. Aparecer a una ventana donde especicamos las propiedades de nuestra autoridad certicadora. Una vez especicados los par ametros, en la siguiente ventana elegimos el tipo de clave privada y la longitud en bits, donde elegimos RSA y 1024 respectivamente.

16

4.3. Exportar Certicado de Autoridad Certicadora.

UAM - Iztapalapa

Figura 4.2: Crear Autoridad Certicadora. Despu es de esto nuestra autoridad est a pr acticamente creada, ahora solo hay que elegir los usos y nalidades que se les puede dar a los certicados que rmar a, para ello seleccionamos el certicado de la nueva autoridad, elegimos Editar Propiedades y seleccionamos la pesta na de Pol tica de la AC.

4.3.

Exportar Certicado de Autoridad Certicadora.

Ya que esta creada la Autoridad Certicadora, el siguiente paso es exportar su certicado, lo cual se hace de la siguiente manera: Seleccionamos la Autoridad Certicadora en la pantalla de gnoMint (en caso de tener m as de una CA), damos click con el bot on derecho del mouse y elegimos Exportar en el men u que aparece. En la ventana que aparece despu es seleccionamos la opci on de S olo la parte p ublica, que exporta el certicado a un archivo en formato PEM. Despu es escribimos el nombre que tendr a el certicado y especicamos la ubicaci on en la que se crear a (por el momento podemos elegir cualquier nombre, posteriormente se explicar a como asignar el nombre adecuado), una vez hecho esto se tiene el certicado de la autoridad.

4.4.

Archivos necesarios para instalar una Autoridad Certicadora en gLite.

Para instalar autoridades certicadoras reconocidas en gLite basta con descargar el repositorio de autoridades e instalarlo mediante yum, al hacerlo de esta forma podemos ver que se crea la carpeta 17

4.4. Archivos necesarios para instalar una Autoridad Certicadora en gLite.

UAM - Iztapalapa

Figura 4.3: Pol ticas para la CA. /etc/grid-security/certicates/ y en ella aparecen grupos de 5 archivos con el mismo nombre pero diferente extensi on, cada grupo de archivos corresponde a una CA y estos b asicamente son el certicado, la CRL y los archivos que describen a la CA. Como en nuestro caso vamos crear la autoridad certicadora es necesario que contemos con estos 5 archivos para poder utilizarla con los servicios y usuarios. Estos archivos tienen un nombre y extensi on espec cos, el nombre como se mencion o es el mismo para todos y la extensi on depende de la funci on de cada archivo. El nombre consta de 8 caracteres y para conseguirlo es necesario que contemos con el certicado root de nuestra autoridad, la forma de obtener el nombre es tecleando en la terminal Linux lo siguiente: [root@host]$ openssl x509 -in certificado root de CA -hash Lo que nos da los 8 caracteres que componen el nombre adem as de mostrarnos el contenido de nuestro certicado. Los archivos de la CA para gLite, as como el contenido de algunos de ellos se describen a continuaci on: El certicado root de la Autoridad Certicadora. ebe2bfad.0: es nuestro certicado en formato PEM La lista de Revocaci on de Certicados (CRL) de la CA. ebe2bfad.crl url: ubicaci on del nuestra lista de revocaci on. http://coral1.izt.uam.mx/crl/ebe2bfad.r0 18

4.4. Archivos necesarios para instalar una Autoridad Certicadora en gLite.

UAM - Iztapalapa

Figura 4.4: Nombre hash para la CA. Para obtener la lista de revocaci on seleccionamos la CA en la pantalla principal de gnoMint, luego en la Barra de Men u elegimos Certicados Generar CRL, seleccionamos la CA de la cual deseamos general la CRL, aparece una ventana en la que especicamos el nombre y ubicaci on del archivo, y con esto generamos la lista revocaci on en un archivo en formato PEM. Las Pol ticas de Firma para la CA. ebe2bfad.signing policy: son las pol ticas en las que se basa la CA, aparece la denici on de la CA, con su Nombre Distintivo (DN) como valor, as como las condiciones de DN para rmar las peticiones de certicado. access_id_CA pos_rights cond_subjects X509 /C=MX/ST=Mexico/L=D.F./O=UAM/OU=Distribuidos/CN=UAM-CA globus CA:sign globus "/C=MX/ST=Mexico/L=D.F./O=UAM/OU=Distribuidos/*"

Informaci on acerca de la CA. ebe2bfad.info: informaci on de la CA, nombre, ubicaci on del certicado root, ubicaci on de la lista de revocaci on, email del administrador de la autoridad, estado de la autoridad, ubicaci on de la autoridad, versi on y la huella digital SHA1. alias = UAM-CA ca_url = http://coral1.izt.uam.mx/cacert/ebe2bfad.0 crl_url = http://coral1.izt.uam.mx/crl/ebe2bfad.r0 email = dsgf@libio.izt.uam.mx status = accredited:classic url = http://www.coral1.izt.uam.mx version = 3 sha1fp.0 = 51:C2:D2:1D:CA:84:60:44:09:89:86:E9:57:2A:34:B0:B0:C3:DF:C0 Espacios de nombres de la CA. ebe2fad.namespaces: Nombre Distintivo de la CA (Emisor) as como posibles Nombres Distintivos de los certicados emitidos. 19

4.5. Crear Certicados de Host y de Usuario.

UAM - Iztapalapa

TO Issuer "/C=MX/ST=Mexico/L=D.F./O=UAM/OU=Distribuidos/CN=UAM-CA" \ PERMIT Subject "/C=MX/ST=Mexico/L=D.F./O=UAM/OU=Distribuidos/.*" Ya con los archivos es necesario que el certicado root (ebe2bfad.0) y la lista de revocaci on (ebe2bfad.r0) de la CA puedan ser accedidos para su consulta v a web, para esto instalamos el servidor web apache en la PC que contiene gnoMint, despu es en la direcci on /var/www/ creamos las carpetas cacert y crl y en cada una de estas copiamos un archivo seg un corresponda, como se muestra a continuaci on: [root@host]$ [root@host]$ [root@host]$ [root@host]$ [root@host]$ apt-get install apache2 mkdir /var/www/cacert mkdir /var/www/crl cp ebe2bfad.0 /var/www/cacert/ cp ebe2bfad.r0 /var/www/crl/

El nombre y ubicaci on de estos archivos puede variar, pero se debe de tomar en cuenta que tienen que ser iguales a los que se especica en los archivos ebe2bfad.crl url y ebe2bfad.info, de otra forma no podr an ser accedidos. Ahora para habilitar nuestra CA en las PCs que contienen servicios gLite s olo es necesario copiar los 5 archivos a la carpeta: /etc/grid-security/certificates/

4.5.

Crear Certicados de Host y de Usuario.

Seleccionamos Certicados A nadir A nadir solicitud de certicaci on. Aparecer a la ventana de propiedades de la solicitud, donde podemos elegir si se heredan o no campos de la autoridad. En la siguiente ventana especicamos las propiedades de la solicitud, en la opci on de Nombre Comun (CN) del certicado se tiene que poner el nombre completo del host o del usuario, dependiendo del n que le daremos al certicado, estos nombres deben de ser exactamente iguales a los denimos en el archivo hosts o en el archivo users.conf de gLite. Seleccionamos el tipo de la clave privada y su tama no, que deben de ser iguales a los elegidos al crear la autoridad certicadora, es decir, RSA y 1024 respectivamente, y con esto nalizamos la solicitud, ahora en la ventana principal de gnoMint podemos observar dos Titulares, Certicados y Solicitudes de certicaci on, en caso de no ver las solicitudes de certicaci on tenemos que habilitar esto en la barra principal con la opci on Ver Solicitudes de certicaci on.

4.5.1.

Firmar solicitudes de certicaci on.

Seleccionamos la solicitud de certicaci on que se desea rmar, para iniciar el rmado hay 3 opciones, la primera es en la barra principal eligiendo Certicados Firmar, la segunda es 20

4.5. Crear Certicados de Host y de Usuario.

UAM - Iztapalapa

Figura 4.5: Solicitud de Certicaci on. con el bot on que aparece en la barra de iconos que simula una rma, y la tercera opci on es dando click con el bot on derecho del mouse sobre la solicitud y seleccionando la opci on Firmar.

Figura 4.6: Firma de solicitud de certicaci on. Aparece una ventana que muestra las propiedades del nuevo certicado, en caso de estar en lo correcto continuamos con el proceso de rmado. Debido a que gnoMint tiene capacidad de administrar varias autoridades certicadoras, en la siguiente ventana en caso de ser necesario se puede seleccionar la autoridad certicadora que rmar a la solicitud. Una vez elegida la autoridad tenemos que especicar la caducidad que tendr a el nuevo certicado, as como los posibles usos y nalidad con los que contar a, con esto se concluye el rmado y en la ventana principal se puede observar que el nuevo certicado deriva de la autoridad que lo rmo.

4.5.2.

Exportar Certicados y Llaves Privadas.

Ya que se ha creado y rmado el certicado en gnoMint, el siguiente paso consiste en exportar el certicado y su llave privada para usarlos en los servicios y usuarios de gLite.

21

4.5. Crear Certicados de Host y de Usuario.

UAM - Iztapalapa

Seleccionamos el certicado que deseamos exportar en la pantalla de gnoMint, damos click con el bot on derecho del mouse y seleccionamos Exportar en el men u que aparece. En la ventana que aparece despu es seleccionamos la opci on de S olo la parte p ublica que exporta el certicado a un archivo en formato PEM. Despu es escribimos el nombre que tendr a el certicado y seleccionamos la ubicaci on en la que se crear a, para un host el nombre del certicado ser a hostcert.pem mientras que para un usuario ser a usercert.pem, una vez hecho esto se tiene el certicado que ser a instalado en los nodos que lo requieran o en las cuentas de usuario. Para la llave privada los pasos son pr acticamente los mismos, s olo que en el men u de Exportar certicado elegimos la opci on de S olo la clave privada (sin cifrar), en cuanto al nombre ser a hostkey.pem para las llaves privadas de host y userkey.pem para los usuarios.

22

Cap tulo 5

Componentes de gLite.
A continuaci on se describir an algunos elementos de los que se compone gLite, estos son s olo los elementos b asicos para la implementaci on de un sitio Grid independiente, es decir, que no necesite de m as elementos para su operaci on.

5.1.

Servicio de Membres a de la Organizaci on Virtual (VOMS).

Es un sistema que permite complementar un certicado proxy con extensiones que contienen informaci on acerca de la VO, los grupos de la VO a los que pertenece el usuario, y el rol que tiene el usuario. Dentro de la terminolog a del VOMS (Virtual Organization Membership Service), un grupo es un subconjunto de la VO que contiene miembros que comparten algunas responsabilidades o privilegios en el proyecto. Los grupos est an organizados jer arquicamente como un arbol de directorio, comenzando desde un grupo ra z de toda la VO. Un usuario puede ser miembro de varios grupos, y un proxy del VOMS contiene la lista de todos los grupos a los que el usuario pertenece, pero cuando se crea el proxy del VOMS, el usuario puede escoger uno de estos grupos como el grupo principal. Un rol es un atributo que t picamente le permite a un usuario adquirir privilegios especiales para llevar a cabo tareas espec cas. En principio, los grupos est an asociados a privilegios que el usuario siempre tiene, mientras que los roles est an asociados a privilegios que el usuario necesita tener s olo de vez en cuando. Para asociar grupos y roles a privilegios espec cos, lo que tiene importancia es la combinaci on grupo/rol, que algunas veces se reere a un FQAN (Fully Qualied Attribute Name). El formato es: FQAN = <group name>[/Role=<role name>] por ejemplo, /cms/HeavyIons/Role=production. Se debe tomar en cuenta que un rol de ninguna manera es global, sino que siempre se asocia a un grupo. El servicio VOMS sigue una arquitectura cliente-servidor, se compone de un servidor (vomsd), un cliente (voms-proxy-init) y algunos servicios auxiliares (voms-proxy-info, voms-proxy-destroy, vomsproxy-list). El VOMS no interact ua directamente con otros servicios, sino a trav es de una API (Application Program Interfaces).

5.1.1.

Procesos ejecut andose sobre el servicio VOMS.

A continuaci on se mencionaran los procesos que deben de ejecutarse sobre el servicio VOMS, normalmente inician cuando la PC es encendida, en caso de que no ocurra as o si se modica la conguraci on del servicio, existe la manera de iniciarlos manualmente, adem as tambi en es posible conocer 23

5.1. Servicio de Membres a de la Organizaci on Virtual (VOMS). su estado, reiniciarlos, detenerlos por completo, etc.

UAM - Iztapalapa

tomcat5. Puede ser iniciado por medio del script /etc/init.d/tomcat5 /etc/init.d/tomcat5 start|stop|restart|condrestart|try-restart|reload| force-reload|status|version voms: es el n ucleo del servicio VOMS. Puede ser iniciado por medio del script /opt/glite/etc/init.d/voms /opt/glite/etc/init.d/voms start|stop|restart|status voms-admin: permite la conguraci on de la VO por medio de una intefaz web. Puede ser iniciado por medio del script /opt/glite/etc/init.d/voms-admin /opt/glite/etc/init.d/voms-admin start|stop|restart|status

5.1.2.

Archivos importantes en el VOMS.

El archivo vomses es un archivo importante para el servicio VOMS, debe de estar en la carpeta /opt/glite/etc/vomses, y es una copia del archivo vomses que distribuyen los servidores VOMS con los que se quiere tener contacto. El archivo consisten en un conjunto de lineas, las cuales tienen el siguiente formato: nick hostname puerto DN del servidor alias versi on de globus Donde: nick: es el nickname que sera usado como el nombre de la VO para el comando voms-proxy-init. hostname: es el host en donde se ejecuta el servidor. puerto: es el puerto por el que se escuchar a. (un puerto para cada VO). DN del servidor: es el DN del certicado del servidor. alias: es ignorado por ahora, pero debe de ser igual al nick. versi on de globus: es opcional, especica la versi on de globus que utilizaremos. Es posible asignar el mismo nick a varios servidores, esto es interpretado por el voms-proxy-init como una declaraci on de servidores con replicas, en este caso se contactan en forma aleatoria hasta que uno de ellos permita la conexi on o hasta que todos la rechacen. Los archivos logs tambi en son importantes en el VOMS, gracias a ellos podemos ver quienes realizaron peticiones para certicados proxy, a quienes se les otorgaron y a quienes se les negaron. Por default los archivos log se guardan de la siguiente manera: /var/log/glite/voms.NombreVO Por lo cual en esta carpeta encontraremos tantos archivos log como VOs se est en administrando en el servidor. Tambi en se encuentran los archivos log para el admin VOMS: 24

5.2. UI (User Interface). /usr/share/tomcat5/logs/catalina.out /usr/share/tomcat5/logs/voms-admin-NombreVO.log

UAM - Iztapalapa

5.2.

UI (User Interface).

La interfaz de usuario es un conjunto de APIs clientes que usuarios y aplicaciones utilizan para tener acceso a la grid. Adem as la UI cuenta con los siguientes componentes: Herramientas para la manipulaci on de la VOMS desde la l nea de comandos. WMS clientes y APIs. L&B clientes y APIs. Comandos para la Transferencia de Archivos y APIs. I/O glite. LFC (Catalogo de Archivos) cliente. API(Application Programming Interface) es un conjunto de pasos y funciones que ofrece alguna biblioteca para ser utilizado por otro software como capa de abstracci on; estas llamadas ofrecen acceso a ciertos servicios desde los procesos y facilitan la programaci on, es decir, con esta herramienta ya no hay necesidad de teclear una gran serie de pasos para conseguir un resultado. Por lo que las APIs proporcionan un conjunto de funciones de uso general. La Interfaz de Usuario (UI) es un servicio que puede estar instalado en cualquier host, el u nico requisito es que este contenga las cuentas de los usuarios; as como sus certicados instalados. Desde una UI un usuario es autenticado y autorizado para hacer uso de los recursos y de cierta informaci on. Los archivos y carpetas de conguraci on para este servicio se muestran a continuaci on: /etc/profile.d/grid-env.sh /etc/profile.d/grid-env.csh /opt/glite/etc /opt/edg/etc Como ya sabemos, en cualquier sistema es muy importante contar con un registro de lo u ltimo que ha acontecido al sistema, esta informaci on nos ayuda a saber porque est a actuando de cierta manera, o simplemente para prevenir alguna inconstancia, estos archivos llamados log para este servicio seguramente ser an de gran utilidad y la ubicaci on de los registros en Linux es: /var/log/ En gLite un job siempre va acompa nando de un proxy, que le da una identicaci on para que el administrador del VO le provea autorizaciones a los dem as recursos de la grid. Es posible la creaci on de dos tipos de proxys. El proxy short que reside en este servicio y tiene un m aximo 24hr de duraci on. Y 25

5.2. UI (User Interface).

UAM - Iztapalapa

el proxy long 1 que reside en el matchmaker un modulo del Worload Manager, y este puede durar hasta una semana. Por lo que para enviar un job primero se debe tener un proxy valido. Segundo, para que el job corra satisfactoriamente sobre la GRID este proxy debe estar actualizado hasta que job termine de ejecutarse, ya que aunque se lograra refrescar el proxy, este no tendr a ning un efecto sobre la copia que lleva el job. De aqu surge la necesidad de crear un proxy largo antes de enviar el job. Entonces el matchmaker permite al proxy short del job ser refrescado por el proxy long una vez que sea requerido. Para la creaci on de un proxy short, si no se especica este se creara por default con una duraci on de 12 hr, y la sintaxis para crearlo es como se ve enseguida: [usuario@host]$ voms-proxy-init --voms nombre vo Para aumentar el n umero de horas es con la opci on: --valid 24:00 Para la creaci on de los proxys se puede usar diferentes par ametros para especicar algunas opciones, por ejemplo con la opci on --confile <ruta> puesto al nal del comando indica que para generar el proxy utilice el archivo de conguraci on vomses de la ruta se nalada. Cuando se usa la opci on --voms se le puede a nadir enseguida un comando para que sea ejecutado en el servidor, su sintaxis es as : --voms vo-alias[:vo-command] Adem as de enviar comandos tambi en es posible especicar el rol o tipo de usuario que lo env a, l ogicamente que esto tiene inuencia para las preferencias en las ejecuciones de los jobs, claro basadas en las pol ticas con las que sea congurado gLite. Si se desea que se cree un proxy para un job con un rol de administrador, bastar a con teclear la siguiente l nea: [usuario@host]$ voms-proxy-init --voms vomstest:/Role=lcgadmin Para revisar si nuestro proxy voms est a bien, solo basta con teclear: [usuario@host]$ voms-proxy-info --all Este comando nos permite ver informaci on, tal como el due no del proxy, las horas validez que le restan, la VO a la que pertenece, adem as de otros atributos. En caso de no ya no se requiera el proxy, es posible eliminarlo, solo basta con teclear la siguiente orden: [usuario@host]$ voms-proxy-destroy Existe otro archivo importante en el servicio UI, este es el archivo vomses que se encuentra en la carpeta:
1

Para la creaci on de un proxy long es necesario contar con un servidor my proxy

26

5.3. Elemento de Computo (CE: Computing Element).

UAM - Iztapalapa

/home/<usuario>/.glite/ Este contiene la informaci on de las VOs a las cuales pertenece el usuario y consiste en un conjunto de lineas en las que se especican las caracter sticas de cada VO, de la misma manera que en el archivo vomses del servicio VOMS. Adem as del archivo anterior, existen archivos para cada VO que cumple con la nalidad del vomses, el nombre de cada archivo esta compuesto de la siguiente manera: <NombreVO>-<ServidorVO> Estos archivos se encuentran en la carpeta: /opt/glite/etc/vomses/

5.3.

Elemento de Computo (CE: Computing Element).

Un Elemento de C omputo (CE), en terminolog a Grid, es una serie de recursos de c omputo ua localizada en un sitio (como puede ser un cl uster). Un CE incluye un Grid Gate (GG)2 , que act como una interfaz gen erica para el cl uster; un Local Resource Management System (LRMS) (llamado tambi en batch system) que es el encargado de la administraci on de los trabajos, y el cluster en s mismo, que funciona como una colecci on de Nodos Trabajadores (WNs), que son los nodos donde se ejecutan los trabajos. Existen dos implementaciones de GG en gLite 3.1: el CE de LCG (LCG CE), desarrollado por el EDG, mantenido por el WLCG y utilizado en LCG-23 , y el CE de gLite (CREAM CE), desarrollado por EGEE. Los sitios pueden escoger cu al instalar, y algunos de ellos proporcionan ambos tipos. Para gLite 3.2 solo es posible utilizar CREAM CE, por lo que las grids basadas en esta versi on de gLite solo pueden contar con este CE. El GG es responsable de aceptar trabajos y enviarlos para su ejecuci on en los WNs a trav es del LRMS. En gLite 3.1, los tipos de LRMS soportados son OpenPBS/PBSPro, LSF, Maui/Torque, BQS y Condor, y trabajando para soportar Sun GridEngine. Vale la pena tener en cuenta que estrictamente hablando, un CE corresponde a una u nica cola en el LRMS, siguiendo la siguiente sintaxis de nombre: CEId = <gg hostname>:<port>/<gg type>-<LRMS type>-<batch queue name> De acuerdo con lo anterior, diferentes colas denidas en el mismo cluster se consideran como diferentes CEs. Esto se usa actualmente para denir colas diferentes para trabajos de distintas extensiones u otras propiedades (por ejemplo el tama no de RAM, tipo de procesador, etc), o de diferentes VOs. Ejemplos de nombres de CE son: ce101.cern.ch:2119/jobmanager-lcglsf-grid alice cmssrv25.fnal.gov:2119/condor-condor-cms
2 3

Para los CEs basados en Globus, se denomina Gatekeeper LCG-2 es la antigua pila de middleware utilizada por el WLCG/EGEE

27

5.3. Elemento de Computo (CE: Computing Element).

UAM - Iztapalapa

gridce0.pi.infn.it:8443/cream-lsf-cms4

5.3.1.

CREAM CE (Ejecuci on y Administraci on de Recursos de C omputo).

CREAM (Computing Resource Execution And Management) es un servicio sencillo y ligero para la administraci on de trabajos a nivel Elemento de C omputo, su denida interfaz WebService y su implementaci on como una extensi on servlet Java-Axis (ejecut andose dentro del contenedor Apache Tomcat) proveen interoperabilidad con clientes escritos en cualquier lenguaje de programaci on y ejecut andose sobre cualquier plataforma. La interfaz CREAM est a denida usando el Web Service Description Lenguage (WSDL); con esto cualquiera podr a generar su cliente CREAM simplemente completando el c odigo auxiliar generado por el analizador WSDL (gSOAP para C/C++, Axis para Java, Perl module para perl). A continuaci on se mencionan las principales funcionalidades del servicio CREAM: Presentaci on de Trabajo. Posibilidad de puesta en marcha directa de archivos input sandbox que cumplan con el lenguaje JDL usado para describir los env os de trabajo en el WMS de gLite. Soporte para trabajos batch y MPI. El soporte para trabajos en masa est a comenzando a ser integrado. Delegaci on de proxy manual y autom atica. Cancelaci on del Trabajo. Informaci on del Trabajo con un nivel congurable del verbosity y ltrado basado en el tiempo de presentaci on y/o estado del trabajo. Lista de Trabajos. Suspensi on o reanudaci on de Trabajos. Autenticaci on basada en GSI. Autorizaci on basada en VOMS. Purgado de trabajos para su terminaci on. Posibilidad (para administradores) de deshabilitar nuevas peticiones. En la gura 5.1 se muestra un esquema general del funcionamiento de la arquitectura del Servicio CREAM. Como se mencion o anteriormente al servicio CREAM se le pueden presentar/enviar trabajos de 2 maneras: 28

5.3. Elemento de Computo (CE: Computing Element).

UAM - Iztapalapa

Figura 5.1: Arquitectura del CREAM-CE. Por el WMS a trav es del servicio ICE (Interface to CREAM Enviroment Interfaz para el ambiente CREAM). Por un cliente gen erico, como lo puede ser un usuario nal que env a directamente trabajos al CREAM CE, por medio de una interfaz de l nea de comandos en C++ y clientes Java. ICE (una capa intermedia gSOAP/C++) es el servicio que interact ua con el WMS cuando se trata de Elementos de Computo basados en CREAM, b asicamente el servicio ICE toma los roles que el Controlador de Trabajo (JC: Job Controller), Condor y el Monitor Log (LM: Log Monitor) juegan cuando no se trata de CEs CREAM, en la gura 5.2 se puede observar esta intercci on entre el servicio WMS y el CREAM. 5.3.1.1. Procesos ejecut andose sobre un CREAM-CE.

A continuaci on se mencionaran los procesos que deben de ejecutarse sobre un Elemento de Computo CREAM, estos normalmente inician cuando la PC es encendida, en caso de que no ocurra as , existe la 29

5.3. Elemento de Computo (CE: Computing Element).

UAM - Iztapalapa

Figura 5.2: Interacci on del servicio ICE. manera de iniciarlos manualmente, adem as tambi en es posible conocer su estado, reiniciarlos, detenerlos por completo, etc. tomcat5 Puede ser iniciado por medio del script /etc/init.d/tomcat5 /etc/init.d/tomcat5 {start|stop|restart|condrestart|try-restart|reload| force-reload|status|version} blahpd Es iniciado autom aticamente por tomcat bdii Puede ser iniciado por medio del script /etc/init.d/bdii /etc/init.d/bdii {start|stop|restart|condrestart|status} globus-gridftp Puede ser iniciado por medio del script /etc/init.d/globus-gridftp /etc/init.d/globus-gridftp {start|stop|restart|status} glite-lb-locallogger (glite-lb-logd and glite-lb-interlogd) Puede ser iniciado por medio del script /opt/glite/etc/init.d/glite-lb-locallogger /opt/glite/etc/init.d/glite-lb-locallogger {start|stop|restart|status} mysqld Puede ser iniciado por medio del script /etc/init.d/mysqld 30

5.4. Nodo Trabajador (WN: Worker Nodo). /etc/init.d/mysqld {start|stop|status|condrestart|restart}

UAM - Iztapalapa

Actualmente mysql puede ser implementado y ejecutado en otra m aquina diferente a la de CREAM CE, pero esta conguraci on a un no es soportada por la herramienta de conguraci on yaim. BLAH blparser Puede ser iniciado por medio del script /opt/glite/etc/init.d/glite-ce-blparser /opt/glite/etc/init.d/glite-ce-blparser {start|stop|restart|status} El BLAH blparser se ejecuta cuando los archivos de registro batch system est an disponibles (lo cual puede ser en el nodo CREAM CE o en un nodo diferente). 5.3.1.2. Ubicaci on de archivos log.

Los archivos log (o de registro) son importantes, ya que por medio de estos podemos saber lo que ocurre dentro de nuestro sistema, y en caso de un error podemos recurrir a ellos para conocer qu e fue lo que causo el mismo, por eso es recomendable conocer cu ales y en donde se encuentran estos archivos de registro. /opt/glite/var/log/*log Pr acticamente todos los archivos logs en esta carpeta nos ayudan a obtener informaci on acerca del funcionamiento general de los servicios de gLite, y en particular para el servicio CREAM el archivo log /opt/glite/var/log/glite-ce-cream.log. Archivos logs para el servicio gridftp. /var/log/globus-gridftp.log. /var/log/gridftp-session.log. /var/log/message. /usr/share/tomcat5/logs/ El archivo log mas importante en esta carpeta es catalina.out. Para cada trabajo presentado a CREAM CE (desde la Interfaz de Usuario o por medio del WMS) se registra la informaci on adecuada en los archivos log que son manejados por el servicio de contabilidad DGAS o por APEL. Estos archivos log de contabilidad generalmente se encuentran en /opt/glite/var/log/accounting

5.4.

Nodo Trabajador (WN: Worker Nodo).

El Nodo Trabajador (WN) es el nodo de c omputo dentro de la grid donde los trabajos de los usuarios (que han sido presentados al Elemento de Computo y al Batch System) nalmente son ejecutados. En el WN los componentes del middleware que son necesarios tales como el Logging and Bookkeeping, Replica manager, File and Storage clients deben ser instalados. 31

5.5. Torque (Batch System).

UAM - Iztapalapa

Los WNs generalmente tienen los mismos comandos y librer as que la UI, adem as de los comandos de gesti on de trabajo. Adicionalmente se pueden instalar otros tipos de software necesarios en el sitio si as lo requiere alguna VO, este software de aplicaci on espec ca se puede preinstalar en los sitios en un area dedicada, generalmente en un sistema de archivo compartido que sea accesible desde todos los WNs.

5.5.

Torque (Batch System).

Torque es un manejador de recursos open source que provee el control sobre los trabajos batch y los nodos de c omputo distribuidos. Este es un esfuerzo comunitario basado en el proyecto original PBS, con m as de 1200 patches que han incluido avances signicativos en las areas de escalabilidad, tolerancia a fallos, as como extensiones hechas por NCSA (The National Center for Supercomputing Applications), OSC (Ohio Supercomputer Center), USC (University of Southern California), the U.S. Dept of Energy, Sandia National Laboratories, PNNL (Pacic Northwest National Laboratory), U of Bualo, TeraGrid y muchas otras organizaci on de vanguardia en el HPC4 . Torque es el servicio que se utilizar a para el batch system, por lo que es necesario instalar junto con los servicios CREAM CE y WN algunos paquetes adicionales (como se ver a en la secci on de instalaci on) para habilitar Torque.

5.6.

WMS (Workload Management System).

El WMS es el servicio de gLite encargado del manejo y distribuci on de trabajos (jobs) sobre los recursos de la grid, principalmente entre los recursos computacionales y de almacenamiento. Este servicio es un regulador de la cargar de trabajo, ya que distribuye de manera eciente los jobs en toda la grid, es decir recibe de un cliente las peticiones sobre ejecuci on de un job buscando los recursos necesarios bas andose en las especicaciones, pues al mandar un job se debe mandar en un lenguaje especial (Job Description Lenguage), el cual detalla el numero de nodos (Workers Nodos) y poder de los cores que necesita, as como la ubicaci on de los datos, adem as de una serie de par ametros. El WMS tambi en permite enviar jobs que al terminar su salida venga a ser entrada de otros jobs, es decir gLite da la facilidad de mandar una colecci on de estos (posiblemente con dependencias entre ellos), haciendo esto mucho m as eciente. El prop osito del WMS es aceptar los trabajos del usuario para asignarles el CE (Computing Element) m as apropiado. Para cada CE se tiene asociado un conjunto de WNs (Worker Nodes), por lo que en este servicio se hace la elecci on del CE m as apropiado, al cual se le enviar a el job; esto se realiza en un proceso llamado match-making; y de los CEs disponibles se escogen aquellos que cumplan con los requisitos expresados por el usuario y que est an cerca de los archivos que necesita el job. Por otra parte el L&B (Logging and Bookkeeping) es el servicio de registro y contabilidad del sistema, el cual rastrea trabajos gestionados por el WMS. Colecta los acontecimientos de muchos
La Computaci on de Alto Rendimiento (HPC: High Performance Computing) es una herramienta que permite aprovechar una gran capacidad de computo para resolver problemas complejos.
4

32

5.6. WMS (Workload Management System).

UAM - Iztapalapa

componentes del WMS y registra el estado e historial del trabajo (Enviar, Correr, Hecho, etc).

5.6.1.

Componentes del WMS.

WMS se considera como el servicio principal en la estructura de gLite; este maneja tanto el envi o como la cancelaci on de los jobs usando algunos comandos de red. En general es un servicio encargado de la programaci on de los jobs de una manera eciente, y para lograrlo solicita informaci on sobre el estatus de la grid en todo momento; para seleccionar el mejor recurso disponible, y en caso contrario retener el job hasta que el recurso que necesita est e listo, esto es como tratar de acomodar piezas sobre alguna supercie que depende del job y sus especicaciones, as como de lo que se tenga a disposici on, claro que no es algo sencillo, ya que tambi en se enfrenta a la situaci on de que constantemente est an llegando trabajos y cada cierto tiempo se desocupan los recursos, por lo que es necesario establecer pol ticas para que la ejecuci on de los jobs que mandan los usuarios para que este proceso sea de manera equitativa. Este es un servicio muy activo conformado de varios componentes, en la imagen de abajo se muestra la estructura de este servicio y la explicaci on de cada uno de ellos:

Figura 5.3: Estructura del WMS. WM (Workload Manager): Es el n ucleo del WMS, quien procesa y satisface las peticiones, es decir; acepta y atiende las solicitudes para administrarlas. Est a conformado por el Task Queue, el Match-Maker, Information Supermarket, Information Updater y el Administrador de Jobs. Pero es responsabilidad del usuario darle una presentaci on antes de enviar un job, esta es escrita con el job description lenguaje, y en el se puede especicar con detalle los recursos de computo (CE y WN) y de almacenamiento (SE) que necesita. Es a trav es de este servicio que se conoce el estatus del envi o de los jobs, al transmitirlo a los dem as servicios y a la Interfaz de Usuario. El WN puede adoptar diferentes pol ticas para la ejecuci on de los jobs, en una pol tica se podr a tener que el job sea pasado a ejecuci on tan pronto como sea posible en cuanto se desocupe el primer recurso, y se conoce como Pol tica de programaci on ansiosa. Y en otra podr a especicarse que se desea ejecutar el job en cuanto est en listos los recursos, por lo tanto se puede ver esto como el envi o de los jobs dependiendo de los recursos que se van desocupando, mejor conocida como Pol tica de programaci on ociosa.

33

5.6. WMS (Workload Management System).

UAM - Iztapalapa

Netwok Service: Es un demonio gen erico de red que provee soporte para el control del job, como lo es el job submittion and removal. NS es el encargado de atender las solicitudes de ejecuci on provenientes de la UI y del mismo WMS, pero antes de esto se asegura de autenticar a los usuarios para la utilizaci on de los recursos del grid, v a los certicados proxy que genera la UI. Una vez que ha validado pasa la solicitud al Workload Manager. Workload Manager Proxy (WMProxy): Recibe peticiones a trav es de la UI para validarlas, como se ha mencionado es un servicio que provee acceso al Workload Manager a trav es de una interface basada en el servicio web. Task Queue: Esta es una cola que administra los trabajos recibidos desde la Interfaz de Usuario, la interfaz entre este y la UI es el Network Service. Una vez que la ejecuci on de un job es enviado al Network Service, la petici on en JDL es interpretada por esta y en seguida es enviada al Task Queue; y llegando la petici on a este modulo el job es encolado en la lista de peticiones para ser enviado al match-maker, una vez llegado a este se verica si est a disponible el recurso adecuado, si es as se manda a ejecutar, y en caso contrario regresa al task queue para ser atendido m as tarde por el match-maker. Match-maker: Componente del work manager encargado de la asignaci on de los mejores recursos disponibles, tambi en conocido como Resource Broker (RB). El match-maker est a conformado de dos partes, el primero es el procesamiento de las solicitudes de los jobs y est a basado en varios criterios, incluyendo pol ticas de acceso, como los son la preferencia de algunos usuarios y la naturaleza de las solicitudes. La otra parte de este modulo solicita informaci on de los recursos y le pregunta al m odulo Information Supermarket el cual contiene la informaci on completamente actualiza sobre los recursos de la grid. Cuando ambas partes est an preparadas, el proceso de matchmaking es optimizado para llevar a cabo la programaci on de las solicitudes de los jobs sobre los recursos disponibles de la grid. Entonces el proceso de solicitud de ejecuci on del job pasa a la siguiente etapa que es el job submission y sea monitoreado y ejecutado sobre los recursos elegidos. Information Supermarket: Este m odulo es pr acticamente el cache donde es almacenado la informaci on general de los recursos de la grid para poder dar respuestas al matchmaker, y este tome las mejores decisiones. La informaci on que reside en este m odulo es constantemente actualizada v a el Infortion Updater. Adem as de todo, gracias a su ecacia tambi en se puede disponer de varias pol ticas a la vez, ya que entrega un reporte detallado y veraz sobre los recursos de la grid. Information Updater: Este componente como se mencion o, constantemente est a actualizando la informaci on en el supermarket, pero la tarea de este m odulo es leer la informaci on del BDII-top, es decir, est a en constante comunicaci on con el servidor de datos Berkeley de m as alto nivel que corresponde a su organizaci on virtual. Esto quiere decir que conoce con seguridad el estatus de los recursos. Job Handler: Cuando el proceso de matchmaking se ha realizado el job es enviado al job handler para ser procesado. Este consiste de cuatro componentes b asicos: Job packaging, job submission and removal y job monitoring. El job packaging que es la forma en la que presentar a el job, a su vez esa conformado por el job adapter y el job controller. En el job adapter el JDL es modicado y crea el ambiente apropiado en el CE para una adecuada presentaci on; enseguida se pasan las modicaciones al job controller que prepara el chero para nalmente enviarlo; y es aqu donde toma el control un proceso llamado Condor (/opt/condor-c/bin/condor) y recibe este chero, quien 34

5.6. WMS (Workload Management System).

UAM - Iztapalapa

es el principal componente encargado de realizar el job submission and removal. El sumitted job es constantemente monitoreado por el log monitor para tomar acciones apropiadas en respuesta al estado que vaya tomando el job durante la ejecuci on, el log monitor tambi en informa de sus descubrimientos al servicio Bookkeepind & Logging. DAGMan (Gag manager): Es un proceso que interact ua con Condor que es un meta-programador quien gestiona el trabajo con dependencias y comienza la ejecuci on del correspondiente job.

5.6.2.

Fases del envi o de un job.

Fase 1: Descubrimiento de los recursos. Autorizaci on. Requerimientos de las aplicaciones. Fase 2: Recopilaci on de la informaci on din amica. Selecci on de los recursos y planicaci on. Fase 3: Espera. Envio del job. Ejecuci on y monitorizaci on. Obtenci on de resultados. El proceso desde que llega un job, hasta que se ejecuta se puede ver en la siguiente descripci on: 1. El demonio Network Server (/var/glite/networkserver) recibe las peticiones desde la Interfaz de Usuario, y utiliza los componentes openssl y/o GSI para la autenticaci on y autorizaci on. Una vez autenticado el usuario, se recibe el job y los datos o cheros de entrada, prepara el trabajo y lo sit ua en una cola de espera. 2. EL WM Coordina la ejecuci on del trabajo: Se extrae el job de la cola de espera. Se manda llamar al match-marker para obtener los recursos compatibles con la solicitud. Selecciona la mejor, dependiendo de la pol tica establecida. Se manda llamar al JobAdapter y sucesivamente al JobController. 3. El Matchmaker: 35

5.6. WMS (Workload Management System). Primero realiza una comunicaci on con el Sistema de Informaci on (BDII). Utiliza Condor ClassAds y matchmaking entre trabajos y recursos Devuelve una lista de los recursos compatibles 4. JobAdapter (/opt/glite/include/glite/wms/helper/jobadapter):

UAM - Iztapalapa

Crea los scrips necesarios para ejecutar el job en alg un(os) WNs del CE seleccionado. Los scrips obtienen: Los archivos de entrada del Manejador del servicio de Datos (DMS). Se establecen las variables de entorno adecuadas. Se invoca al ejecutable del job (mpi, normal, etc) Ver sistaxis JDL Todo los cambios y/o errores se registran en el modulo LB Se guarda la salida y se registran replicas de informaci on en caso de especicarse en la solicitud. Se limpia todos los archivos temporales e innecesarios

5. Job Controller: Que es la interfaz con Condor, para el envi o correcto y seguro de jobs u otra operaci on. 6. LogMonitor: Ubicado en: /var/glite/logmonitor/. Este registra los eventos de Condor. A continuaci on se puede observar c omo se relacionan algunos servicios con los procesos explicados anteriormente.

Figura 5.4: Interacci on de los procesos del WMS.

36

5.6. WMS (Workload Management System).

UAM - Iztapalapa

5.6.3.

Interacci on del WMS con otros servicios del middleware.

Recursos. WN (Nodos Trabajadores). CE (Elementos de Computo). SE (Elementos de Almacenamiento). Servicio de Informaci on BDII. L&B. Como se puede observar en la imagen 5.4, la mayor a de los componentes del workload manager est an interactuando con el L&B, informando cada etapa por la que un job pasa y de su administraci on. Tambi en se puede ver que en el proceso del matchmaking se requiere de la interacci on con el Data Manager para consultar el Catalogo de archivos y conocer m as sobre la manera en que se puede hacer referencia a estos y as resolver su localizaci on; este servicio cuenta con un DLI (Data Location Interface) basado en el matchmaking para encontrar archivos en el grid. Tambi en el WMS tiene cierta comunicaci on aunque indirecta con la VOMS al leer informaci on acerca de la VO, conocer acerca de los usuarios y grupos a los que pertenecen, as como de sus permisos. De igual manera le interesa saber acerca de los permisos proxy otorgados para la autenticaci on. Adem as es el servicio encargado de repartir los recursos de la mejor forma, por lo que tiene comunicaci on con los CEs a trav es de Condor, ya que est a constantemente recibiendo noticaciones sobre sus recursos. Y como se mencion o con anterioridad hay una estrecha e importante relaci on del information update con el BDII para conocer el estado de general de la grid.

5.6.4.

Seguridad en el WMS.

La estructura de WMS debe ser robusta para comunicarse con los otros servicios y manejar adecuadamente la carga de trabajo, para esto es importante que cuente con mecanismos de seguridad que garantice que los recursos van a ser utilizados apropiadamente. Debido a estos, las interacciones de sus componentes con los otros servicios van a mutuamente autenticadas, aunque estas dependen de la interacci on. Una entidad puede autenticarse por si misma o por otra igual usando credenciales propias o una credencial de usuario o ambas. Se ha comentado que a la llegada de una solicitud para ejecutar un job de la Interfaz de Usuario al Network Service se autentica el certicado proxy generado en la UI. Lo mismo se tiene cuando el WMS-UI interact ua con el servicio L&B, el WMS-UI usa una credencial proxy para limitar el riesgo de comprometer las credenciales originales en manos de los usuarios. Para tener niveles de seguridad aceptables es necesario que la identidad del usuario o servicio venga incluido en un certicado X.509 junto con su llave privada, el certicado debe estar rmado por una Autoridad Certicadora, que garantice que la llave en verdad es del usuario que se nala el certicado. Una vez que un job se ha enviado de la UI al WMS; como vimos este pasa por varios componentes y procesos, por lo que cada operaci on requiere una autenticaci on de un certicado, como el accesar a 37

5.7. SE (Storage Element)

UAM - Iztapalapa

cierta informaci on, el WM necesita conocer al usuario y sus credenciales, de igual forma este necesita ser validado por el job controller y condor cuando el job es asignado a alg un CE. Por lo que la validaci on del certicado es necesario durante el todo el tiempo de vida del job. Tambi en un job es asociado a un certicado proxy cuando este es enviado desde la UI; la validaci on del certicado es por default de 12 horas, a menos que una validaci on explicita sea requerida por el usuario mientras la creaci on del proxy.

5.7.

SE (Storage Element)

Este servicio es fundamental, debido a que tanto los usuarios como los programas requieren datos, y la mayor a de las veces estos datos solo son de lectura; cuando se est a corriendo un programa que simula alg un fen omeno qu mico se genera gran cantidad de datos, y en ciertos casos hay adem as replicas de informaci on para garantizar un acceso r apido y la recuperaci on si llegara a fallar alg un equipo. SE es el servicio de almacenamiento que utiliza gLite, donde los datos que se manejan solo tienen permisos de lectura. Para el manejo de informaci on gLite utiliza una herramienta llamada DPM (Disk Pool Manager) es un juego de Sistemas de Archivo localizados en uno o m as servidores de discos. Ahora cada SE-DPM est a compuesto de dos elementos: un nodo principal (head node) y por un servidor de discos (disk server); cada nodo principal puede poseer uno o m as servidores de discos, los cuales son a nadidos a este mediante el uso de la herramienta yaim. El DPM cliente debe estar instalado en los nodos trabajadores (WN) y en la interfaz de usuario (UI). Este servicio no es otra cosa m as que una interfaz entre la grid y el sistema de almacenamiento, conocido como SRM (Storage Resource Manager) y su funci on b asica es la de garantizar el almacenamiento f sico, gestionar replicas, permitir lecturas, descargas y actualizaciones. Uno de los retos a los que se enfrenta la administraci on de este servicio es la distribuci on de la informaci on por diferentes hosts que posiblemente utilizan distintos m etodos de acceso; o a sistemas de archivos no compartidos, esto se considera, ya que es muy com un que los datos se est en moviendo de un lugar a otro. Por lo que es necesario tener un est andar para accesar y manipular esta informaci on, y aqu entran las interfaces SRM. Cuando la informaci on o la generaci on de esta van en aumento puede resultar dif cil localizarla, por lo que es necesario llevar un control o ndice de bloques de datos; y para esto se tiene el File Catalog. Pero claro tampoco puede faltar el servicio o mejor dicho el protocolo que se utilizar a para la transferencia de datos, a este subservicio se le conoce como FTS, adem as del servicio de almacenamiento y la encriptaci on de los datos. Son cuatro m odulos que conforman al Data Management, y se describen a continuaci on: 1. Almacenamiento. Donde los archivos est an f sicamente localizados. Storage URL o SURL tambi en conocidos como Physical File Name (PFN). La referencia a un archivo es: srm://[direcci on]

38

5.7. SE (Storage Element)

UAM - Iztapalapa

2. Cat alogo. En File Catalogue (LFC) hay un mapeo de la direcci on f sica de los archivos a una direcci on l ogica, usando una estructura de directorios jer arquico. Conocido como Local File Name LFN Una referencia a un archivo como este se puede ver as : lfn:<cualquier nombre> lfn:/[direcci on] 3. Almacenamiento Encriptado. La herramienta Hydra es de las comunes para la seguridad de la informaci on. 4. Transporte. Encargado de leer o escribir archivos en discos remotos, y se vale del Servicio de Transferencia de Archivos (FTS), y el Transporte URL o TURL, un movimiento de este u ltimo se ver a as : <Protocolo>://[direcci on] Uno de los protocolos m as usados para el movimiento de archivos en glite son: gsiftp, ro y gsidcap. Es necesario mencionar que el Transporte URL es obtenido din amicamente del SURL o nombre f sico a trav es del Sistema de informaci on SI o de la interfaz SRM. Adem as de lo anterior cada archivo en glite est a compuesto por un identicador u nico Grid Unique IDentier (GUID) que consta de 36 bytes y es de la siguiente forma: guid:<nombre unico de 16 bytes> Tanto los usuarios como las aplicaciones necesitan localizar los archivos o replicas en el grid. El Cat alogo de Archivos (File Catalogue) que hace un mapeo entre los LFN, GUID y SURL. El File Catalogue publica el servicio URL en el Sistema de Informaci on (SI) para que sea descubierto por el Data Management Tools y otros servicios. En si el cat alogo consiste de una llave principal que viene siendo el Logical File Name.

Figura 5.5: Mapeo entre identicadores de archivos. Como se ha mencionado antes, la organizaci on de este servicio es esencial ya que al contar con un buen sistema de b usqueda y de almacenamiento por ende las operaciones que requieren y generan datos son ecientes. Hemos visto la ventaja de manejar los Nombres l ogicos a partir de los Nombres f sicos, y los Identicadores (GUID) que les asigna la grid, la l ogica con que estos identicadores se han organizado es con el n generar Metadatos, para optimizar en un futuro su b usqueda, los metadatos vienen siendo como lo es el ndice en un libro, o como la etiqueta que trae un producto enlatado, con solo observarla sabemos r apidamente que es lo que contiene sin necesidad de abrirlo. Esta idea se muestra en la siguiente imagen:

39

5.8. BDII (Berkeley Database Information Index).

UAM - Iztapalapa

Figura 5.6: Metadatos de Archivos. El Cat alogo de Archivos (LFC), dispone de un LFC-Cliente y un LFC-Servidor, para administrarlo se cuenta con una terminal o bien por medio de un API, ya que gracias a la librer a que posee (Grid File Access Library) se puede tener acceso al Cat alogo de una manera transparente. En el Data Movement para que un archivo est e disponible en la grid, l ogicamente debe existir f sicamente en alg un SE y registrado en el Cat alogo. Para el movimiento de los datos, este subservicio cuenta con tres niveles de herramienta para moverlos: Nivel bajo. Un ejemplo es enviar archivos de los WN y de la UI hacia SE. Y se apoya del uso de las CLIs Globus/gridftp. Nivel medio. Es el usado para poner datos del SE en los servicios WN y UI; usando la CLI de Storage Resource Manager (SRM). Nivel Alto. Se enfoca en la r eplica y copia de archivos entre varios SEs; vali endose del Cat alogo de Archivos (LCF). Que al aumento de los recursos e informaci on de la grid se convierte en la mejor opci on para el correcto desempe no de este.

5.8.

BDII (Berkeley Database Information Index).

El BDII es parte del Sistema de Informaci on (SI), este servicio le proporciona datos a la grid sobre el estado de los recursos que posee. El BDII recopila informaci on de forma peri odica; este se encuentra organizado en forma de a rbol, en donde el BDII-top de m as alto nivel puede ser consultado por el usuario, o bien por otros servicios. El BDII consiste de una base de datos est andar LDAP, la cual es actualizada por un proceso externo; este proceso es el LDIF el cual recaba informaci on del status y lo integra, para despu es compararlo con la base de datos, una vez que se tiene las diferencias se crea un archivo LDIF, el cual es usado para actualizar la base de datos. 40

5.8. BDII (Berkeley Database Information Index).

UAM - Iztapalapa

Ahora la LDAP (Lightweight Directory Access Protocol) es un protocolo ligero de acceso a directorios; est a basado en la norma X.500 (X.500 es un est andar ISO que dene un modelo universal para servicios de directorios distribuidos) de servicios de directorio, corre en el protocolo TCP/IP. LDAP es un conjunto de protocolos abiertos a nivel de aplicaci on que permite el acceso a un servicio de directorio para buscar diversa informaci on en un entorno de red. En este contexto un directorio es un conjunto de objetos con atributos, organizados de manera l ogica y jer arquica. Este puede almacenar informaci on como: autenticaci on, ubicaci on de los recursos en la red, certicados, etc. LDAP es un servicio global de directorios, y dene el transporte y formato de los mensajes para comunicarse. LDAP se puede ver como una base de datos de objetos que pertenecen a diferentes clases. Una caracter stica de este tipo de bases a diferencia de otras es en su habilidad para operaciones de lectura, b usqueda y navegaci on. Las entradas para un directorio LDAP est an estructuradas en forma de a rbol jer arquico, y como es de suponerse, entre mayor sea la profundidad del a rbol mayor ser a su precisi on de la informaci on que contenga. A la parte m as alta de esta estructura se le conoce como la ra z; y el nombre con que se identica a alg un nodo desde la ra z se conoce como: Nombre Diferenciado (DN) del nodo. Es muy com un que un directorio LDAP muestre l mites geogr acos o de car acter organizacional.

Figura 5.7: Estructura de un a rbol LDAP. Si observamos la imagen 5.7 podemos comprender que el circulo en amarillo representa a nuestra organizaci on; los c rculos en verde muestran un l mite de car acter organizacional, y se les conoce como unidades organizacionales; mientras que al analizar un nodo podemos ver como se hace referencia a el, comenzando de abajo hacia arriba, y a toda la descripci on de los nodos a los que depende se le conoce como DN (Nombre Descriptivo). LDAP es un servicio de directorios distribuidos y como tal puede utilizarse para almacenar varios tipos de informaci on, tales como im agenes, texto, binarios, etc. Otro de los usos que tiene es que puede servir para autenticar usuarios, tal como lo hace NIS, puede tambi en almacenar la informaci on que reside en los registros DNS. De igual manera que otros protocolos existe la interacci on cliente-servidor, por lo que si alg un cliente no puede establecer comunicaci on con un servidor porque este no pueda 41

5.8. BDII (Berkeley Database Information Index).

UAM - Iztapalapa

decidirlo, puede acudir a un servidor LDAP superior para que determine si atiende la solicitud.

5.8.1.

Terminolog a de LDAP.

Objeto: El objeto es la entidad m nima de un directorio LDAP, y a cada uno se le llama por su nombre diferenciado (DN). Atributos: Estos son la informaci on asociada a un objeto, tal como los nombres, puestos, etc. objectClass: Es un atributo especial. Todos los objetos en LDAP deben de poseer este atributo, es importante ya que dene cuales atributos requiere el objeto, as como las clases de objetos que puede tener. Las deniciones de este se almacenan en archivos schema. Schema: Un esquema es una serie de reglas que determina la estructura y contenido de un directorio, dene que clases puede contener y que atributos son obligatorios y cuales opcionales. LDIF: LDAP Data Interchange Format (Formato de intercambio de datos LDAP). Este es un archivo de texto plano para objetos LDAP. Los archivos que importan o exportan datos hacia y desde un servidor LDAP se deben hacer en este formato, y de igual manera se usa para la duplicaci on de servidores LDAP. Cabe se nalar que los demonios utilizados del lado del servidor son: slapd dise nado para escuchar y atender las conexiones LDAP hechas desde los clientes; su archivo de conguraci on se ubica en /etc/openldap/slapd.conf. slurpd es usado para la duplicaci on, as como para propagar los cambios de una base de datos a otra, sincroniza cambios de un servidor a otro, y es usado solo cuando se tiene m as de un servidor LDAP. Igual que cualquier aplicaci on est a equipado de sus ordenes para modicar objetos, a nadir, eliminarlos, establecer una contrase na para un usuario LDAP, consultar alg un directorio, generar contrase nas con encriptaci on, etc. Como se mencion o, BDII es un servidor LDAP, y en la grid es importante y cr tico este servicio, ya que depende de este para que la grid funcione adecuadamente. Debido a que provee de informaci on detallada sobre los servicios del gLite, y es muy necesario para las diferentes tareas. La implementaci on de este servicio es de forma jer arquica, donde basta con solo tener una estructura de tres niveles, por lo que la informaci on del servidor de m as bajo nivel se le va a conocer como BDII a nivel de recursos o primarios, y estos servidores son los encargados de tener informaci on acerca de los CEs y SEs. Para cada BDII a nivel de recursos recibe informaci on solo de un par de estos servicios, y de igual manera estos est an asociados solo con un BDII primario. Posteriormente el BDII de en medio, conocido como BDII a nivel de sitio va a recopilar la informaci on de varios BDIIs primarios, y el conjunto de estos se le va a conocer como un sitio, Este BDII a nivel de sitio estar a informando a todos los BDII que se encuentra en la capa superior, conocidos como BDII de m as alto nivel (BDII-top), y estos a su vez estar an proveyendo de informaci on a quien lo solicite. La ventaja de que esto ocurra as es grande, ya 42

5.8. BDII (Berkeley Database Information Index).

UAM - Iztapalapa

Figura 5.8: Estructura del Servicio BDII. que hay replicaci on de informaci on, cada BDII de m as alto nivel conoce la situaci on de la grid, y si en un momento se llegara a caer alguno, siempre existir a al menos uno que puede resolver las peticiones. En el diagrama 5.8, podemos notar que el hecho de que estos servidores usen LDAP tiene mucho sentido. Como apreciamos en este, cada BDII a nivel de recursos es un servicio local; y el BDII a nivel de sitio, conocer a acercar de sus recursos para el sitio en que ha sido congurado. Otra ventaja que se puede tener con los BDII-top es que en las solicitudes de informaci on se pueden repartir el trabajo con el balanceador de carga, y as volverse menos propensos al fault tolerant. Los BDIIs son famosos por ser proveedores de informaci on; ya que poseen scrips los cuales obtienen la informaci on en el formato LDIF, y lo convierten a un formato est andar. El ser proveedores de informaci on facilita que la estructura jer arquica sea posible. El Proveedor de Informaci on Gen erica (GIP) es un framework el cual facilita el despliegue de la informaci on, e instala algunos plugins para soportar nuevos sistemas. Como vimos en la terminolog a LDIF, se utiliza un schema que determina los atributos y deben ser encontrados din amicamente de un sistema espec co. Para evitar la duplicaci on de los proveedores de servicios GIP se vale un mecanismo de plugins y as obtener los valores din amicos. El GIP lee todos los archivos LDIF de un directorio est atico. Dependiendo del estado de la cache, la informaci on provista en el directorio Provider y los plugins din amicos encontrados en el directorio 43

5.9. L&B (Logging and Bookeping)

UAM - Iztapalapa

Plugin se ejecutan, y su salida se almacena en un directorio temporal antes de actualizar la cache. Cuando los proveedores o plugins son ejecutados, un archivo candado es colocado en un directorio candado para detener todas las instancias que podr an depositarse. El nombre diferenciado (DN) es usado para identicar los valores y atributos que tienen la misma entrada. La informaci on de las entradas puestas en el cache resultado de ejecutar el proveedor de informaci on sobrescribir a las entradas de los archivos est aticos. Ahora los valores puestos en el cache de los plugins din amicos sobrescribir an los valores de los archivos est aticos y/o de los proveedores de servicio. El resultado es un LDIF y despu es es convertido a una salida est andar. El Freedom of Choice for Resource (FCR), es usado dentro del BDII top para habilitar la Organizaci on Virtual (VO), su existencia es muy importante para la conguraci on de otros servicios, y los servicios de los que dispone pueden ser modicados a trav es de un portal de conguraci on.

5.9.

L&B (Logging and Bookeping)

El middleware es una herramienta dise nada para tener acceso veloz a una gran cantidad de recursos de almacenamiento y procesamiento, como ya se ha mencionado esta tecnolog a est a conformada de un conjunto de servicios cooperando entre s , ocultando la complejidad del sistema al ejecutar las tareas de una manera transparente para el usuario. La funci on del middleware consiste en manejar una gran cantidad de jobs que utilizan recursos de c omputo y almacenamiento entre distintas redes. Lo cual involucra una gran interacci on de los numerosos componentes que pueden generar errores. Dependiendo de la causa del error se puede obtener una inuencia sobre el sistema, desde un retraso en la ejecuci on de un job, o en el peor de los casos puede comprometerlo deteniendo por completo el funcionamiento entero del sistema. Por lo que los creadores de gLite vieron necesario implementar un modulo para el monitoreo y manejo de los jobs, as como de los mensajes de control entre los m odulos. Por lo que el servicio L&B es fundamental para el correcto y eciente desempe no del sistema. La manera de trabajar de este servicio es almacenando informaci on sobre la ejecuci on de los jobs, es decir, este dispone de la informaci on actual de un job, y tambi en va creando un historial de los estados que se van generando durante tal proceso. El L&B es un servicio que est a en constante comunicaci on con el subm odulo Job submission and motitoring que pertenece al WM que a su vez pertenece a WMS. Tanto el CE como el WMS generan eventos y los env an al LB server para actualizar sus datos, para esto se cuenta con una librer a que dene el protocolo encargado de comunicar el logger con el server. LB cuenta con dos componentes para el registro de los jobs, por una parte se tiene los componentes Logger que constantemente est a enviando informes al componente LB Server sobre la situaci on de cada job. En la siguiente imagen se puede observar este procedimiento:

5.9.1.

Componente Logger.

B asicamente se encarga del log de los eventos, de su almacenamiento able, y del reenv o al server LB, este componente est a integrado fundamentalmente por dos demonios: 44

5.9. L&B (Logging and Bookeping)

UAM - Iztapalapa

Figura 5.9: Funcionamiento del Servicio LB. 1. Local-logger Acepta los eventos entrantes, a nade un archivo por job al disco local del servicio, y lo reenv a a inter-Logger 2. Inter-Logger Es el encargado de enviar al LB server, gestiona la cola de entrega, si hay fallas las recupera, y entrega los archivos cuando los eventos han sido resueltos.

5.9.2.

Componente Server.

Este recibe los eventos, los analiza, los almacena y los procesa para ser puestos a disposici on para consulta de los usuarios, y toda su informaci on descansa sobre mysql. Cuando un usuario solicita una consulta sobre alg un job, el resultado de la consulta es ltrado y la consulta se transforman en consultas SQL y el resultado se vuelve al usuario. La consulta completa no est a disponible, con el n de proteger este servicio y evitar los ataques de negaci on de servicio intencional o no intencional.

5.9.3.

Estados de transici on de un job.

Despu es de obtener un certicado digital de una Autoridad de Certicaci on de conanza, el registro en una VO y la obtenci on de una cuenta en una interfaz de usuario, el usuario est a listo para usar los servicios de la Grid. Accede a la interfaz de usuario (UI) y crea un certicado proxy para autenticar el job en las interacciones de este con otros servicios y procesos. Los posibles estados por los cuales puede atravesar un job en la Grid son los siguientes:

45

5.9. L&B (Logging and Bookeping)

UAM - Iztapalapa

Submitted: El job es introducido por el usuario a trav es de la Interfaz de Usuario (IU). Waiting: El job ha sido aceptado por el NS, y est a en espera para ser atendido por el Workload Manager; con ayuda del componente matchmaker se interroga al servicio Information Supermarket para determinar el estado de los recursos de computo y de almacenamiento, as como el Catalogo de Archivos (LFC) para localizar los archivos de entrada. Ready: El job es preparado por el WMS para ser enviado, y el cual dispone de un scrip para presentar el job de una manera adecuada, adem as de pasarlo con algunos par ametros necesarios al CE. Scheduled: El CE recibe y la solicitud, y es puesta en su cola para su futura ejecuci on. Runing: El job es ejecutado en los nodos trabajadores (WN) que pertenecen al CE seleccionado. Done: Si el job naliza sin errores, los resultados del proceso son enviados de los WNs al nodo maestro (CE) y del CE al WMS, y nalmente este informa de lo sucedido a la interfaz de usuario. Cleared: En este punto, el usuario puede recuperar la salida (sandbox) de su trabajo desde la interfaz de usuario, o tambien puede ser limpiada por el sistema debido al t ermino de tiempo. Aborted: El job que se encontraba en proceso ha sido abortado por el WMS por el largo tiempo de espera en WN o en CE, o por t ermino de la validaci on de sus credenciales. Canceled: El job es cancelado exitosamente por una petici on del usuario. Todo el tiempo desde que se env a, hasta que espera por los recursos o ser atendidos por estos, e incluso ya durante la ejecuci on el job puede ser detenido. Failed: Es posible que durante la ejecuci on se presente alg un faul, puede deberse al manejo de los datos, apuntadores de un tipo diferente y operaciones no permitidas.

Figura 5.10: Posibles Estados de un Job.

46

5.10. Lenguaje de Descripci on de Trabajo (JDL).

UAM - Iztapalapa

5.10.

Lenguaje de Descripci on de Trabajo (JDL).

El JDL (Job Description Language) es un lenguaje de alto nivel basado en el lenguaje Classied Advertisement (ClassAd), utilizado para describir trabajos y conjuntos de trabajos. El JDL es usado en WLCG/EGEE para especicar las caracter sticas del trabajo y limitaciones que se desean, que son tomados en cuenta por el WMS para seleccionar el mejor recurso para ejecutar el trabajo. Para describir un trabajo se utiliza un archivo (llamado archivo JDL) que consiste de l neas que tienen el formato: atributo = expresi on; Las expresiones pueden abarcar varias lineas, pero s olo la ultima debe de terminar con punto y coma. Las cadenas literales se encierran entre comilla dobles. Si una cadena en s contiene comillas dobles, deben ser precedidas con una diagonal invertida (por ejemplo: Arguments = \hello\ 10. El caracter no puede ser usado en el JDL. Los comentarios deben ser precedidos por el caracter # o doble diagonal (//) al principio de cada linea. Los comentarios multiples deben ser encerrados entre /* y /*. El JDL es sensible a los caracteres en blanco y los tabuladores, por lo que no hay caracteres en blanco o tabuladores seguidos del punto y como al nal de una linea. A continuaci on se muestran algunos ejemplos de archivos JDL para comprender mejor su uso. Para denir un trabajo que ejecuta el comando hostname en el WN, escribir un archivo JDL como este: Executable = /bin/hostname; StdOutput = std.out; StdError = std.err; El atributo Executable especica el comando a ejecutar por el trabajo. Si el comando ya esta presente en el WN, debe ser expresado como una ruta absoluta, si tiene que ser copiado desde la UI, solo debe ser especicado el nombre del archivo, y se debe de especicar la ruta del comando en la UI en el atributo InputSandbox. Por ejemplo: Executable = test.sh; InputSandbox = /home/doe/test.sh; StdOutput = std.out; StdError = std.err; El atributo Arguments puede contener un valor de cadena, el cual es tomado de la lista de argumentos para el ejecutable: Arguments = fileA 10; En el Executable y en los atributos Arguments puede ser necesario el uso de caracteres especiales, tales como &, \, , >, <. Si estos caracteres deben ponerse en la shell (por ejemplo, si forman parte del nombre de un archivo), deben ser precedidos por triple \\\ en el JDL, o especicados en el interior de cadenas entre comillas. Los atributos StdOutput y StdError denen el nombre de los archivos que contienen la salida 47

5.11. Servicio NTP.

UAM - Iztapalapa

est andar y el error est andar del ejecutable, una vez que la salida del trabajo es recuperada. Para la entrada est andar, tambi en se puede especicar un archivo de entrada: StdInput = std.in; pero este atributo se utiliza raramente. Si varios archivos tienen que ser copiados desde la UI para el nodo de ejecuci on, deber an de ser listados en el atributo InputSandbox: InputSandbox = {test.sh, fileA, fileB, ...}; S olo el archivo especicado como Executable tendr a autom aticamente la bandera de ejecuci on; si hay otros archivos en el InputSandbox con esta bandera en la UI, la pierden cuando se copian al WN. Finalmente, los archivos a ser transferidos de vuelta a la UI despu es de que se termine el trabajo, se especican usando el atributo OutputSandbox: OutputSandbox = {std.out, std.err};

5.11.

Servicio NTP.

NTP, o Network Time Protocol, es un protocolo dise nado para sincronizar los relojes los sistemas inform aticos a trav es de la red. NTP utiliza UDP como su capa de transporte, usando el puerto 123 y est a dise nado para resistir los efectos de la latencia variable. Un servidor NTP primario o Stratum 1, est a conectado a un reloj de referencia de alta precisi on, esta referencia puede ser, por ejemplo, un reloj at omico, o un receptor de radio o GPS. Adem as, este servidor cuenta con software para manejar el protocolo NTP. Otras computadoras, que funcionan como servidores Stratum 2, utilizan un software similar (o el mismo), y consultan autom aticamente al servidor primario para sincronizar su reloj. A su vez, estos pueden sincronizar a otros servidores, que en este caso ser an Stratum 3, y as puede seguirse hasta 16 niveles. La arquitectura tambi en soporta que un cliente haga sus consultas a m as de un servidor y puede haber comunicaciones entre servidores de un mismo Stratum. Cuanto m as alejado est e una computadora del reloj de referencia (mientras m as alto sea su Stratum) menos precisa ser a la sincronizaci on. Sin embargo, cualquier Stratum siempre ser a suciente para que el reloj no se aleje m as de unos milisegundos de la hora real. Una m aquina cliente es aquella que puede sincronizarse con otra o con alguna referencia externa, aunque tambi en puede comportarse como servidor, y utilizarse para sincronizar otras. Siempre que haya una asociaci on entre dos m aquinas, donde una se comporte como cliente, y otra como servidor, al cliente le corresponder a el Stratum inmediatamente superior al del servidor. Hay otra posibilidad, donde dos o m as m aquinas se conguran para comportarse entre s como clientes o servidores, seg un qui en est e m as cerca de un reloj de referencia, o qui en sea m as conable de acuerdo con el algoritmo que rige la sincronizaci on por NTP. En este tipo de asociaciones, los servidores se llaman Peers. Para utilizar NTP en una organizaci on, recomendamos instalar un servidor que se sincronice con 48

5.12. Archivo users.conf.

UAM - Iztapalapa

varias fuentes externas. Este servidor ser a la u nica referencia horaria en la organizaci on y todos los equipos estar an sincronizados con el. Este ajuste es de gran importancia ya que permite, entre otras, la correlaci on de eventos entre diferentes equipos. De aqu la importancia de este servicio en gLite, ya que los elementos que lo componen pueden estar en diferentes lugares y por tanto manejar diferentes zonas horarias, por lo que aqu entra el NTP para tener sincronizados los eventos que ocurren durante la ejecuci on de un trabajo.

5.12.

Archivo users.conf.

Este archivo dene los usuarios UNIX que se crear an en los nodos de servicio para poder ser utilizados (principalmente en los servicios CE y WN). El archivo no debe de tener ning un espacio en blanco, y consiste en l neas de texto en donde cada una dene a un usuario, el formato de cada l nea se describe a continuaci on: UID:LOGIN:GID1[,GID2,...]:GROUP1[,GROUP2,...]:VO:FLAG:] UID: ID de usuario. Este debe de ser un UID valido, debemos de estar seguros que el n umero que se elija no est e asignado a otro usuario. LOGIN: nombre de inicio de sesi on. GID1: ID del grupo primario. Debe de ser un GID valido, el n umero elegido no debe estar asignado a otro grupo. GID2: ID de grupo secundario. GROUP1: nombre del grupo primario. GROUP2: nombre del grupo segundario. VO: nombre de la organizaci on virtual. FLAG: cadena para identicar a los usuarios especiales.

5.12.1.

Cuentas ordinarias pool.

Las cuentas pool permiten la asignaci on din amica de nombres de usuario UNIX locales para los usuarios Grid. Para cada VO soportada, se debe de denir un conjunto de cuentas ordinarias pool. Los identicadores de las cuentas pool deben terminar en d gitos que siguen a una cadena base, ejemplo user001. Las cuentas ordinarias pool deben de tener el par ametro FLAG vac o. Las cuentas ordinarias pool solo deben de pertenecer a un solo grupo. 49

5.12. Archivo users.conf.

UAM - Iztapalapa

5.12.2.

Cuentas especiales pool.

Un subconjunto de usuarios en una VO pueden ser asignados a conjuntos dedicado de cuentas, por ejemplo, para recibir una mayor prioridad en el batch system o para tener acceso a alguna cola dedicada. Para cada categor a el administrador del sitio puede denir una FLAG para identicar las cuentas correspondientes. En el archivo groups.conf la misma FLAG tiene que ser usada para marcar los atributos VOMS correspondientes al subconjunto de usuarios. Los identicadores de las cuentas especiales pool deben terminar en d gitos que siguen a una cadena base, ejemplo sgmuser01. Las cuentas especiales pool deben de tener una FLAG identicando el tipo de usuario especial, ejemplo sgm. Las cuentas especiales pool deben pertenecer a m as de un grupo. Podemos identicar tres casos de cuentas especiales: sgm: usuarios sgm, con permisos de escritura en el a rea de software compartido. prd: usuarios prd, con privilegios de administrador de producci on, si es necesario. PILOT JOB FLAG: los usuarios pilot (usuarios para realizar pruebas de nuevo software o nueva caracter stica de una Grid) pueden ejecutar el comando glexec. Esta variable es parte de la conguraci on glexec WN, no lanzado para la producci on. Si est a ejecutando pruebas pps (Pre Production Services) se puede elegir cualquier identicador. Para su conguraci on se debe de revisar en la tarjeta VO-ID cual es el valor dato por la VO. Las cuentas especiales pool normalmente tienen su propio grupo como grupo primario y el grupo de la VO como grupo secundario. Esto permite por ejemplo que el a rea de software compartido tenga permisos de escritura para usuarios sgm y de lectura para el resto de la VO: 40102:sgmuser03:1530,1500:vomstestsgm,vomstest:vomstest:sgm YAIM tiene problemas si las cuentas especiales pool no tienen m ultiples grupos. Si no es necesario un grupo primario diferente, el grupo VO puede especicarse dos veces, por ejemplo: 40102:sgmuser03:1500,1500:vomstests,vomstest:vomstest:sgm Aunque para este mismo resultado tambi en se puede utilizar la siguiente sintaxis (valida desde glite-yaim-core >= 4.0.4-x): 40102:sgmuser03:1500,-:vomstests,-:vomstest:sgm Una vez descritas las opciones de conguraci on para el archivo users.conf, mostramos el contenido del archivo que se cre o para ser utilizado en los servicios gLite: 10100:user000:1500:vomstest:vomstest:: 10101:user001:1500:vomstest:vomstest:: 50

5.13. Archivo groups.conf.

UAM - Iztapalapa

10102:user002:1500:vomstest:vomstest:: 20100:prduser01:1510,1500:vomstestprd,vomstest:vomstest:prd 20101:prduser02:1510,1500:vomstestprd,vomstest:vomstest:prd 20102:prduser03:1510,1500:vomstestprd,vomstest:vomstest:prd 30100:piluser01:1520,1500:vomstestpil,vomstest:vomstest:pilot 30101:piluser02:1520,1500:vomstestpil,vomstest:vomstest:pilot 30102:piluser03:1520,1500:vomstestpil,vomstest:vomstest:pilot 40100:sgmuser01:1530,1500:vomstestsgm,vomstest:vomstest:sgm 40101:sgmuser02:1530,1500:vomstestsgm,vomstest:vomstest:sgm 40102:sgmuser03:1530,1500:vomstestsgm,vomstest:vomstest:sgm

5.13.

Archivo groups.conf.

En el archivo groups.conf se denen las clases de usuarios que deben de ser aceptadas por los servicios Grid de un sitio. Para cada categor a se indica el tipo de cuentas locales que se deben de asignar a un usuario. El archivo consiste en l neas de texto y cada una de estas representa la denici on de una clase de usuarios, el formato se describe a continuaci on: "VOMS FQAN":GROUP:GID:FLAG:[VO] VOMS FQAN: VOMS proxy fully qualied attribute name. GROUP: grupo UNIX. GID: GID UNIX. FLAG: cadena para identicar a los usuarios especiales. VO: organizaci on virtual (opcional, permite especicar la VO de forma expl cita, de lo contrario se deriva de la VOMS FQAN) El archivo groups.conf lista los proxy VOMS FQAN primarios que ser an aceptados. Si un proxy tiene un FQAN secundario que coincide con uno de los FQAN de la lista, la cuenta asignada puede recibir un GID secundario extra correspondiente al FQAN que coincidi o. El GID normalmente se deriva de las cuentas correspondientes en el archivo users.conf. Si no hay cuentas dedicadas a ese FQAN, el GID extra (si lo hay) y el nombre del grupo deben de ser dados en groups.conf. Tenga en cuenta que: Es normal que el segundo y tercer campo est en vacios. La cuenta correspondiente al FQAN primario no tiene que pertenecer a ning un grupo secundario: la librer a LCMAPS puede establecer grupos secundarios independientes de los que est an en /etc/group.

51

5.13. Archivo groups.conf.

UAM - Iztapalapa

El orden de las l neas en groups.conf es importante: para cualquier FQAN solo la primera coincidencia se toma. La FLAG selecciona un conjunto de cuentas especiales que se utilizar an para el mapeo, es decir, aquellas cuentas en users.conf que tienen la misma bandera. Por default, cuando la bandera esta vac a, se usan las cuentas ordinarias pool. Los identicadores para cuentas especiales son exactamente los mismos que se describieron para el archivo users.conf, por lo que no se volver an a detallar en esta secci on. Ahora mostraremos el contenido del archivo groups.conf que se cre o y utiliz o para la instalaci on de los servicios de gLite: /vomstest/ROLE=lcgadmin:::sgm: /vomstest/ROLE=production:::prd: /vomstest/ROLE=pilot:::pilot: /vomstest::::

52

Cap tulo 6

Instalaci on de los Servicios gLite.

En este cap tulo se describir a la implementaci on del middleware gLite, se asume que el sistema operativo ya esta funcionando por lo cual se comenzar a a partir de la instalaci on y conguraci on de los servicios que lo componen. (Para conocer el proceso de instalaci on y conguraci on del sistema operativo puede consultar el Ap endice). Para la instalaci on de los servicios se descargaron los repositorios necesarios para cada uno, debido a que se utilizaron servicios de gLite 3.1 y 3.2 no todos los archivos .repo se encontraron en la misma direcci on, a continuaci on se muestran la ubicaci on de cada repositorio: Para gLite 3.1: http://grid-deployment.web.cern.ch/grid-deployment/glite/repos/3.1/ Para gLite 3.2: http://grid-deployment.web.cern.ch/grid-deployment/glite/repos/3.2/ Para la conguraci on de los servicios de gLite, el archivo llamado site-info.def es el m as importante, de este se encuentra una plantilla en la ruta: /opt/glite/yaim/examples/siteinfo/. Esta plantilla contiene una lista de todas las variables que necesitan los servicios de gLite, por lo que es un archivo muy extenso, como el sitio que se congurar a es b asico no son necesarias todas estas variables, debido a esto s olo utilizamos la plantilla para conocer la descripci on de cada variable. Como direcci on de los archivos de conguraci on en nuestro caso creamos una carpeta en /home/, llamada instalacion, y dentro de esta carpeta se cre o un archivo en blanco con el nombre de siteinfo.def , en este archivo s olo se especicar an las variables necesarias para el tipo de grid que se requiere. Cabe aclarar que por ser una grid de prueba se colocaron los archivos de conguraci on en esta carpeta, para la implementaci on de una grid que no sea de prueba lo recomendable es colocar estos en una carpeta que no sea accesible para los usuarios. Cuando instalamos cualquier servicio de gLite, tambi en se instala un script que ayudara a la conguraci on del servicio correspondiente. Este script se llama yaim y se encuentra en la siguiente ruta: /opt/glite/yaim/bin/ Es recomendable poner este ejecutable de manera permanente en el PATH, ya que la conguraci on es un poco m as laboriosa, y seguramente tendr a que ejecutarse varias veces hasta conseguir depurar todos los errores. La manera para a nadir una ruta de un ejecutable permanentemente es de la siguiente manera: Editar el archivo /root/.bashrc y escribir al nal del archivo la ruta total del PATH mas la que se desea a nadir, as como se muestra: PATH=$PATH:/opt/glite/yaim/bin/ La ruta es hasta la carpeta donde se encuentra el ejecutable. 53

6.1. Conguraci on del Servidor NTP.

UAM - Iztapalapa

El siguiente paso es actualizar estos cambios, para ello teclearemos en la l nea de comandos esto: [root@host]$ source .bashrc Ahora cada vez que necesitemos usar el scripy yaim, ya no hay que recordar toda la ruta, si no escribirlo en el int erprete de comandos, as como si ejecutaras alg un comando del sistema.

6.1.

Conguraci on del Servidor NTP.

La conguraci on del servicio NTP en los sistemas Scientic Linux se realiza modicando el archivo /etc/ntp.conf. Las siguientes son variables de un archivo de conguraci on b asico: # agregamos los siguientes servidores de tiempo server 3.mx.pool.ntp.org server 3.north-america.pool.ntp.org server 2.north-america.pool.ntp.org # si no encuentra un servidor checa el reloj local server 127.127.1.0 minpoll 4 # indicamos el stratum, debido a que la referencia no es exacta fudge 127.127.1.0 stratum 10 # Difusi on hacia los clientes broadcastclient # archivo donde se guarda el factor de correcci on driftfile /etc/ntp.drift # archivo donde se guardan las claves para autenticar conexiones keys /etc/ntp.keys Adem as de la conguraci on del archivo /etc/ntp.conf es necesario que modiquemos o agreguemos un par de reglas del rewall para que de esta forma el servidor NTP pueda sincronizar su hora por medio de otros servidores as como tambi en que pueda difundir esa sincronizaci on con los clientes. Las siguientes l neas tienen que ser agregadas al archivo /etc/syscong/iptables: -A INPUT -s 192.168.0.251 -p udp --dport 123 -j ACCEPT -A OUTPUT -d 192.168.0.0/255.255.255.0 -p udp --sport 123 -j ACCEPT La primera l nea permite la entrada de datos provenientes del puerto 123 de la m aquina 192.168.0.251, en este caso la m aquina no tiene conexi on directa a internet, su entrada/salida la hace a trav es de un Gateway, por lo que no se especica directamente los servidores a los que se conectara, sino que se permite la entrada desde la maquina que funciona como Gateway. La segunda l nea indica que se permite la salida a trav es del puerto 123 a toda la red, esto con el n de difundir el horario a todas las m aquinas conectadas a la misma red que esta.

54

6.2. Conguraci on de los clientes NTP.

UAM - Iztapalapa

6.2.

Conguraci on de los clientes NTP.

La conguraci on de los clientes tambi en se realiza a trav es del archivo /etc/ntp.conf, y es muy similar a la del servidor. A continuaci on se muestra el archivo de conguraci on b asico para los clientes NTP: # agregamos el servidor de tiempo server 192.168.0.112 # si no encuentra un servidor checa el reloj local server 127.127.1.0 minpoll 4 # archivo donde se guarda el factor de correcci on driftfile /etc/ntp.drift # archivo donde se guardan las claves para autenticar conexiones keys /etc/ntp.keys Como se puede observar solo agregamos nuestro servidor NTP local en lugar de los servidores externos. Tambi en es necesario modicar el rewall para que permita la comunicaci on con el servidor, y para ello agregamos la siguiente l nea al archivo de conguraci on del rewall: -A INPUT -s 192.168.0.112 -p udp --dport 123 -j ACEPT Con esta l nea permitimos que exista comunicaci on con nuestro servidor NTP a trav es del puerto 123.

6.3.

Repositorio jpackage.

Este repositorio es necesario para los servicios de gLite 3.1, para gLite 3.2 los paquetes de java que se encuentran dentro de los repositorios principales son sucientes, en esta secci on se describe la manera en que este repositorio se puede a nadir al sistema. A pesar de que hay un repositorio de java que se encuentra en la direcci on ocial de gLite se decidi o utilizar el que se localiza en http://www.jpackage.org/yum.php. Los pasos a seguir son los siguientes: Accedemos a la carpeta donde se guardan los archivos de repositorios: [root@host]$ cd /etc/yum.repo.d/ Creamos el archivo jpackage.repo con el siguiente contenido: [jpackage-1.7-generic] name=JPackage 1.7, for generic #baseurl=MIRROR/VERSION/generic/free/ mirrorlist=http://www.jpackage.org/mirrorlist.php?dist=generic&type=free &release=1.7 enabled=1 gpgcheck=1 55

6.4. Instalaci on de Certicados de Host y de Usuario

UAM - Iztapalapa

[jpackage-1.7-redhat-el-4.0] name=JPackage 1.7, for Red Hat Enterprise Linux 4 #baseurl=MIRROR/VERSION/redhat-el-4.0/free/ mirrorlist=http://www.jpackage.org/mirrorlist.php?dist=redhat-el-4.0 &type=free&release=1.7 enabled=1 gpgcheck=1 Se elige la versi on 1.7 debido a que esta versi on contiene todos los paquetes necesarios para los servicios de gLite. Puede ser posible que durante la instalaci on se solicite la instalaci on de una llave, para ello se realiza lo siguiente: [root@host]$ rpm --import http://www.jpackage.org/jpackage.asc

6.4.

Instalaci on de Certicados de Host y de Usuario

Como se ha visto la seguridad en gLite juega un papel muy importante, es por eso que para establecer conexiones entre un servicio y otro es necesario que cada uno de estos cuenten con un certicado valido, de igual manera para que un usuario pueda hacer uso de los servicios grid, es necesario que cuente su certicado. En esta secci on describiremos como se instala cada uno de estos certicados. Certicados de Host. Los pasos a seguir para la instalaci on de un Certicado Host son los siguiente: Contar con el Certicado Host en un archivo en formato PEM con el nombre hostcert.pem, el cual debe tener el Nombre Distintivo escrito de la misma manera que el hostname de la PC. Contar con la Llave privada, en un archivo en formato PEM con el nombre hostkey.pem. Estos 2 archivos se tienen que copiar a la carpeta /etc/grid-security/ (en caso de que no exista se debe de crear). Una vez copiados se le asignan diferentes permisos a cada uno. Para el archivo hostcert.pem: [root@host]$ chmod 644 hostcert.pem Para el archivo hostkey.pem: [root@host]$ chmod 400 hostkey.pem Certicados de Usuario. Contar con el Certicado de Usuario en un archivo en formato PEM con el nombre usercert.pem, el cual debe tener el Nombre Com un escrito de la misma manera que el nombre de usuario. 56

6.5. Instalaci on de glite-VOMS.

UAM - Iztapalapa

Contar con la Llave privada, en un archivo en formato PEM con el nombre userkey.pem. Estos 2 archivos se tienen que copiar a la carpeta .globus (en caso de que no exista se debe de crear), que debe de estar dentro de la carpeta home del usuario. Una vez copiados se le asignan diferentes permisos a cada uno. Para el archivo usercert.pem: chmod 644 usercert.pem. Para el archivo userkey.pem: [root@host]$ chmod 400 userkey.pem Los archivos deben de pertenecer al usuario, en caso de que esto no suceda, como usuario root debemos de cambiar el propietario de los archivos: [root@host]$ chown <usuario>:<grupo> usercert.pem

6.5.

Instalaci on de glite-VOMS.

El VOMS es el servicio encargado de administrar las Organizaciones Virtuales, en el hay que especicar los par ametros de nuestra VO, tales como el nombre, batch system, el puerto (un puerto para cada VO, a partir del 15000), as como otros par ametro adicionales que mencionaremos m as adelante. Ya que esta instalado y congurado el sistema operativo, se congura tambi en el servicio ntp cliente y procedemos a instalar el servicio gLite. Para empezar a bajar los repositorios accedemos a la carpeta donde se guardan los archivos de repositorios: [root@host]$ cd /etc/yum.repo.d/ Creamos una carpeta: [root@host]$ mkdir otros Movemos el repositorio dag que viene por default a la carpeta que acabamos de crear: [root@host]$ mv dag.repo ./otros/ Obtenemos el repositorio dag de gLite: [root@host]$ wget http://grid-deployment.web.cern.ch/grid-deployment/glite/repos/ 3.2/dag.repo Para el instalar servicio VOMS en gLite 3.2 existen 2 opciones, una es con el manejador de base de datos Oracle y la otra con Mysql, en nuestro caso instalamos la versi on con Mysql. El repositorio lo obtenemos de la siguiente manera: [root@host]$ wget http://grid-deployment.web.cern.ch/grid-deployment/glite/repos/ 3.2/glite-VOMS mysql.repo Una vez que tenemos el repositorio la instalaci on del servicio se realiza como se muestra a continuaci on: [root@host]$ yum install glite-VOMS mysql 57

6.5. Instalaci on de glite-VOMS.

UAM - Iztapalapa

Instalados los paquetes del servicio, colocamos los certicados host, como se describe en la secci on Instalaci on de Certicados Host y de Usuario. Tambien debemos de congurar el password de administrador de mysql asegurandonos de que sea el mismo que se especica en el archivo de conguraci on que se crea m as adelante, para la conguraci on de mysql tecleamos los siguientes comandos como usuario root: [root@host]$ /usr/bin/mysqladmin -u root password <Contrase~ na >; [root@host]$ /usr/bin/mysqladmin -u root -h <Hostname> password <Contrase~ na >; Terminado el proceso de instalaci on de los archivos del servicio, colocamos los certicados de Host, como se describe en la secci on Instalaci on de Certicados Host y de Usuario.

6.5.1.

Conguraci on de glite-VOMS.

Ahora comenzamos con la conguraci on del servicio, para ello creamos la carpeta /home/instalacion/ y dentro de esta un archivo llamado site-info.def que es el contiene los par ametros de conguraci on necesarios para el servicio, tambi en es necesario copiar a esta carpeta los archivos users.conf y groups.conf, para el VOMS en particular es necesario crear una carpeta y dentro de esta otro archivo, la carpeta se llama services y el archivo glite-voms. A continuaci on se muestra y describe el contenido de los dos archivos de conguraci on para el servicio glite-VOMS: Archivo site-info.def : # Nombre del sitio SITE_NAME=glite-tablet.izt.uam.mx # Contase~ na mysql MYSQL_PASSWORD="glite" ####################################### # Variables de configuracion de la VO # ####################################### # Lista de las VO soportadas en el sitio VOS="vomstest" # Contrase~ na de la BD VOMS_DB_PASS="glite" # Ubicaci on de los archivos users.conf y groups.conf USERS_CONF=/home/instalacion/users.conf GROUPS_CONF=/home/instalacion/groups.conf

58

6.5. Instalaci on de glite-VOMS. Archivo glite-voms : # El nombre de host de la VOMS VOMS_HOST=localhost # Host donde se encuentra la DB VOMS_ADMIN_DB_HOST=localhost ################################## #Informacion de la VO "vomstest" # ################################## # Host donde se encuentra la DB de vomstest VO_VOMSTEST_VOMS_DB_HOST="localhost" # Tipo de DB VO_VOMSTEST_VOMS_DB_TYPE="mysql" # Administrador de la DB VO_VOMSTEST_VOMS_DB_USER="root" # Contrase~ na del administrador de la DB VO_VOMSTEST_VOMS_DB_PASS="glite" # Nombre de la DB VO_VOMSTEST_VOMS_DB_NAME="db_vomstest"

UAM - Iztapalapa

# Puerto por el que se escuchar an las peticiones de "vomstest" VO_VOMSTEST_VOMS_PORT="15001" VOMS_ADMIN_SMTP_HOST="localhost" VOMS_ADMIN_MAIL="dsgf@libio.izt.uam.mx" VOMS_DB_DEPLOY="true" Una vez que se tienen los archivos de conguraci on, ejecutamos el comando yaim para aplicar la conguraci on del servicio: [root@host]$ yaim -c -s /home/instalacion/site-info.def -n glite-VOMS Revisamos que el servicio de mysql este funcionando, en caso contrario lo iniciamos manualmente: [root@host]$ service mysqld start Para poder utilizar cli (Command Line Interface] voms-admin ejecutamos: [root@host]$ source /etc/profile.d/grid-env.sh Revisamos que existe el archivo vomses en la carpeta /opt/glite/etc/vomses/, en caso contrario lo creamos, el contenido para este archivo es: 59

6.5. Instalaci on de glite-VOMS.

UAM - Iztapalapa

Figura 6.1: Salida de la conguraci on del servicio VOMS. vomstes tablet3.izt.uam.mx 15001 /C=MX/ST=Mexico/L=D.F./O=UAM/ OU=Distribuidos/CN=tablet3.izt.uam.mx vomstest Agregamos a un usuario como administrador VOMS/VOMS-Admin, en este caso al usuariouser000 : [root@host]$ /opt/glite/sbin/voms-db-deploy.py add-admin --vo vomstest --cert usercert.pem Tambi en se puede agregar un administrador de la siguiente manera: [root@host]$ voms-admin --vo <Nombre VO> create-user <certificado> assign-role VO VO-Admin Con esto se concluye la conguraci on b asica, para comprobar si el servicio voms-admin esta activo para la VO, es posible hacerlo mediante un buscador web: https://<hostname del servidor voms-admin>:8443/voms/<Nombre VO> O se pueden listar las VOs que estan conguradas en el host: https://<hostname del servidor voms-admin>:8443/vomses Lo que en nuestro caso es: https://tablet3.izt.uam.mx:8443/voms/vomstest https://tablet3.izt.uam.mx:8443/vomses Antes de poder comprobar el funcionamiento del voms-admin es necesario importar el certicado del usuario administrador al explorador web, en un principio al no hacer esto aparecia un error que aparentaba ser por un incorrecto certicado del servidor, este error se muestra en la imagen 6.2. 60

6.5. Instalaci on de glite-VOMS.

UAM - Iztapalapa

Figura 6.2: Error con el voms-admin.

6.5.2.

Importar un certicado de usuario al explorador web.

Para importar el certicado de usuario al explorador web, es necesario que se cuente con este en formado .p12, el cual puede obtenerse directamente desde gnoMint, pero en nuestro caso como tenemos el certicado y la llave privada en formato .pem podemos obtener el certicado .p12 a partir de estos, como se muestra a continuaci on: [root@host]$ openssl pkcs12 -export -out usercert.p12 -inkey userkey.pem -in usercert.pem Antes de crear el certicado, se nos solicita que tecleemos una contrase na para cifrar el archivo .p12 y despues de esto el certicado esta listo. Para importar el certicado tenemos que realizar los siguientes pasos, cabe aclarar que estos pasos son para el explorar de web refox, para otros exploradores los pasos a seguir puden ser diferentes: Abrimos el explorardor refox, en la barra de menu seleccionamos Editar Preferencias. En la ventana que aparece seleccionamos la opci on de Avanzado y la pesta na de Cifrado, aqu podemos administrar lo referente a los certicados y validaciones de servidores y dispositivos. Elegimos la opci on de Ver certicados, aparece una ventana que muestra la informaci on de los certicados que tenemos instalados, tanto certicados de Personas, Servidores, CAs, etc., adem as de mostrar la informaci on tambi en permite que importemos certicados si asi lo deseamos. En la primera pesta na Sus certicados seleccionamos Importar, buscamos el certicado .p12 que importaremos y aceptamos, se nos pedir a la contrase na que se utilz o para cifrar el certicado, una vez hecho esto, podemos ver un mensaje que comprueba que el certicado fue importado con exito. Despu es de importar el certicado, es posible entrar a la interfaz web del voms-admin; en caso de tener varios certicados instalados al abrir la pagina web se nos preguntar a que certicado utilizar. 61

6.5. Instalaci on de glite-VOMS.

UAM - Iztapalapa

Figura 6.3: Certicado importado. Es posible que cualquier usuario con un certicado v alido pueda entrar a la intefaz web, pero si no esta registrado como administrador voms-admin no puede realizar ninguna modcaci on, por lo cual no debe de haber problemas con esta situaci on.

6.5.3.

Agregar usuarios a la VO

Para agregar un usuario a la VO, es necesario que un administrador entre a la interfaz web vomsadmin de la forma que se explic o antes. En la intefaz web se selecciona Browse VO User, que muestra los usuarios registrados en la VO, adem as de que permite registrar nuevos usuarios dando click en la parte superior derecha en Add a new user. Al agregar un nuevo usuario, es necesario registrar la informaci on de este, como el nombre, apellido, direcci on, etc., lo m as importante en el registro es el Subject (DN) del nuevo usuario, que es el que comprobar a el VOMS al recibir una petici on de rmado proxy. Completado el registro del nuevo usuario, este ya forma parte de la VO, por lo tanto es mostrado en la lista de usuarios de la VO. La interfaz web no solo permite a nadir nuevos usuarios, sino que hace posible toda la administraci on de la VO; a nadiendo, eliminando y suspendiendo usuarios, as como administrando el nivel de privilegios de cada uno puede tener. Por el momento solo agregamos nuevos usuarios sin involucrarnos tanto en los privilegios que puede llegar a tener cada uno. En la siguiente imagen podemos observar la interfaz web del voms-admin, as como los nuevos usuarios que se crearon como parte de la VO.

62

6.6. Instalaci on de glite-UI.

UAM - Iztapalapa

Figura 6.4: Interfaz web voms-admin.

6.6.

Instalaci on de glite-UI.

Una vez instalado y congurado el sistema operativo, se congura el servicio ntp servidor en este host, para despues obtener los repositorios necesarios para gLite 3.2, para este servicio no es necesario instalar el certicado de host. Para iniciar la instalaci on del servicio accedemos a la carpeta donde se guardan los repositorios: [root@host]$ cd /etc/yum.repo.d/ Obtenemos el repositorio para la UI de gLite: [root@host]$ wget http://grid-deployment.web.cern.ch/grid-deployment/glite/repos/ 3.2/glite-UI.repo Una vez teniendo esto se limpia el cache de instalaci on: [root@host]$ yum clean all Actualizamos el sistema: [root@host]$ yum install update Iniciamos la instalaci on del servicio: [root@host]$ yum groupinstall glite-UI

63

6.6. Instalaci on de glite-UI.

UAM - Iztapalapa

6.6.1.

Conguraci on de glite-UI.

Para el servicio se ha creado una carpeta bajo /home con el nombre de instalacion, y dentro de este el archivo site-info.def que contendr a todas las variables necesarias para levantar el servicio correctamente, de igual manera en esta carpeta se deben de copiar los archivos users.conf y groups.conf. Este es el contenido del archivo site-info.def para el servicio glite-UI: # Nombre del sitio SITE_NAME=glite-tablet.izt.uam.mx # Nombre del Host que contiene al Sistema Manejador de Trabajo WMS_HOST=tablet9.izt.uam.mx RB_HOST=tablet9.izt.uam.mx PX_HOST=tablet10.izt.uam.mx # Nombre del host que almacena a la Base de Datos BDII_HOST=tablet6.izt.uam.mx # Host que lleva el registro de los servicios y recursos del grid. LB_HOST=tablet6.izt.uam.mx # Ruta de los archivos que contienen a los usuarios y grupos de la grid. USERS_CONF=/home/instalacion/users.conf GROUPS_CONF=/home/instalacion/groups.conf # Nombre de nuestra Organizacion Virtual VOS="vomstest" QUEUES="vomstest" VOMSTEST_GROUP_ENABLE="vomstest" VO_SW_DIR=/opt/exp_soft ############ # VOMSTEST # ############ VO_VOMSTEST_VOMS_SERVERS=vomss://tablet3.izt.uam.mx:8443/voms/vomstest?/vomstest/ VO_VOMSTEST_SW_DIR=$VO_SW_DIR/vomstest VO_VOMSTEST_DEFAULT_SE=$DPM_HOST VO_VOMSTEST_STORAGE_DIR=$DPM_STORAGE_DIR/vomstest VO_VOMSTEST_VOMSES=vomstest tablet3.izt.uam.mx 15001 /C=MX/ST=Mexico/L=D.F./ O=UAM/OU=Distribuidos/CN=tablet3.izt.uam.mx vomstest VO_VOMSTEST_VOMS_CA_DN=C=MX/ST=Mexico/L=D.F./O=UAM/OU=Distribuidos/CN=UAM CA Con el archivo site-info.def listo, ejecutamos el script yaim para aplicar la conguraci on: 64

6.6. Instalaci on de glite-UI.

UAM - Iztapalapa

[root@host]$ yaim -c -s /home/instalacion/site-info.def -n glite-UI

Figura 6.5: Salida de la conguraci onde la UI. Despu es de levantar las variables adecuadas y correr el archivo de conguraci on en ocasiones el mensaje de salida es fallido, por lo que fue necesario ir depurando los errores hasta tener una respuesta satisfactoria como se muestra en la salida de la conguraci on. Con la UI esta congurada, es necesario ir agregando los usuarios que podran utilizar los servicios grid: [root@host]$ useradd user000 Con lo anterior se crea el usuario y su carpeta home, dentro de esta carpeta creamos otra llamada .globus y colocamos aqu los certicados de usuario como se explica en la secci on Instalaci on de Certicados de Host y de Usuario.

6.6.2.

Creaci on de certicado proxy.

Ahora ya es posible acceder como usuario a la UI, a continuaci on se muestra la creaci on de un certicado proxy (en particular para el usuario user000) necesario para el env o de un jop: Iniciar sesi on como usuario de la grid: [root@host]$ su user000 65

6.6. Instalaci on de glite-UI. Comprobar existe el archivo vomses en la carpeta /home/user000/.glite/.

UAM - Iztapalapa

Comprobar que existe el archivo de la VO en la carpeta /opt/glite/etc/vomses/, en nuestro caso el archivo se debe de llamar vomstest-tablet3.izt.uam.mx, y tanto este como el archivo vomses deben de tener el siguiente contenido: vomstes tablet3.izt.uam.mx 15001 /C=MX/ST=Mexico/L=D.F./O=UAM/ OU=Distribuidos/CN=tablet3.izt.uam.mx vomstest Ejecutar el comando para la creaci on del proxy, como se mencion o el comando voms-proxy-init tiene varias opciones, en particular se ejecut o el comando con opciones extras para ver m as detalladamente la creaci on del proxy: [root@host]$ voms-proxy-init --voms vomstest -debug -verify

Figura 6.6: Creaci on del proxy. En la imagen 6.6 se puede observar los archivos de conguraci on que se consultan para la creaci on del proxy, as como la conexi on satisfactoria que se realiza con el servidor VOMS que administra la VO vomstest. Antes de llegar a este punto tuvimos complicaciones, entre las cuales estan: Error con el certicado de usuario, esto debido a la conguraci on de los archivos de la CA, ya que los par ametros Issuer y Subject del archivo .namespaces no estaban especicados adecuadamente. En un principio hab a problemas constantes con la lista de revocaci on, y esto se deb a a que esta caducaba cada 24 horas, el problema se corrigi o modicando su tiempo de validez en la opci on de Pol tica de la AC en gnoMint.

66

6.7. Instalaci on del WMS.

UAM - Iztapalapa

Al intentar crear el proxy el servidor VOMS devolv a el mensaje de que el usuario no pertenec a a la VO, ya que no se hab a podido dar de alta por que no se ten a acceso a la interfaz web voms-admin, una vez que el usuario se dio de alta en la voms-admin el problema se solucion o.

6.7.

Instalaci on del WMS.

En este servicio fue necesario instalar la versi on 3.1 de glite, ya que para la reciente versi on 3.2, aun no se cuenta con los repositorios, como ya vimos es un servicio imprescindible. Recordemos que glite 3.1 trabaja sobre un sistema de 32 bits, por lo que tuvimos que instalar Scientic Linux 4.8. Una vez instalado el Sistema Operativo, se debe de instalar el servicio ntp cliente, mientras que para la instalaci on del WMS los pasos a seguir son: Empezar a bajar los repositorios, para lo cual accedemos a la carpeta donde se guardan los archivos repo. [root@host]$ cd /etc/yum.repo.d/ Obtenemos el repositorio para WMS de gLite. [root@host]$ wget http://grid-deployment.web.cern.ch/grid-deployment/glite/repos/ 3.1/glite-WMS.repo Una vez teniendo esto se limpia el cache de instalaci on. [root@host]$ yum clean all Luego se actualiza el sistema. [root@host]$ yum install update Con esto ya podemos instalar el paquete. [root@host]$ yum install glite-WMS Con esta instrucci on se descargaran aproximadamente 200 MB Es necesario aclarar que hay la posibilidad de que la versi on del SO no est e actualizado, y a la hora de la instalaci on marque error al intentar descargar alg un paquete y no encontrar el arbol de repositorios. Este no fue el caso para esta servicio, en caso contrario es necesario hacer la instalaci on paquete por paquete, usando el instalador rpm. Terminada la instalaci on del servicio es necesario instalar el certicado de host antes de continuar con la conguraci on. Adem as hay que congurar el password de administrador de mysql, y asegurarse que sea el mismo que en el archivo de conguraci on, para esto se realiza lo siguiente: [root@host]$ /usr/bin/mysqladmin -u root password <Contrase~ na >; [root@host]$ /usr/bin/mysqladmin -u root -h <Hostname> password <Contrase~ na>;

67

6.7. Instalaci on del WMS.

UAM - Iztapalapa

6.7.1.

Conguraci on del WMS.

Comenzamos con la conguraci on del servicio, para ello creamos la carpeta /home/instalacion/ y dentro de esta un archivo llamado site-info.def que es el contiene los par ametros de conguraci on necesarios para el servicio, tambi en deben de ser copiados a esta carpeta los archivos users.conf y groups.conf. Para la conguraci on del servicio WMS se requiri o levantar las siguientes variables:: # Nombre del Sitio Grid SITE_NAME=glite-tablet.izt.uam.mx # Nombre del host que contiene a la Base de Datos BDII_HOST=tablet6.izt.uam.mx # Password que usara el servicio para autentificarse con mysql MYSQL_PASSWORD=glite # Direcci on de los usuarios y grupos que contiene el grid. USERS_CONF=/home/instalacion/users.conf GROUPS_CONF=/home/instalacion/groups.conf # Host que contiene al Elemento de Almacenamiento SE_LIST=tablet7.izt.uam.mx # Host que lleva el registro los jobs que se ejecutan en el grid. LB_HOST=tablet6.izt.uam.mx SITE_EMAIL=dsgf@libio.izt.uam.mx # Nombre de nuestra Organizaci on Virtual VOS="vomstest" VO_SW_DIR=/opt/exp_soft QUEUES=${VOS} VOMSTEST_GROUP_ENABLE="vomstest" ############ # VOMSTEST # ############ VO_VOMSTEST_VOMS_SERVERS=vomss://tablet3.izt.uam.mx:8443/voms/vomstest?/vomstest/ VO_VOMSTEST_SW_DIR=$VO_SW_DIR/vomstest VO_VOMSTEST_DEFAULT_SE=$DPM_HOST VO_VOMSTEST_STORAGE_DIR=$DPM_STORAGE_DIR/vomstest VO_VOMSTEST_VOMSES=vomstest tablet3.izt.uam.mx 15001 /C=MX/ST=Mexico/L=D.F./ O=UAM/OU=Distribuidos/CN=tablet3.izt.uam.mx vomstest VO_VOMSTEST_VOMS_CA_DN=C=MX/ST=Mexico/L=D.F./O=UAM/OU=Distribuidos/CN=UAM CA 68

6.8. Instalaci on de glite-WN y glite-CREAM.

UAM - Iztapalapa

Ya con el archivo de conguraci on listo lo siguiente es aplicar la conguraci on con el comando yaim como se muestra a continuaci on: [root@host]$ yaim -c -s site-info.def -n glite-WMS Antes de que se tuviera una conguraci on satisfactoria se tuvo que pasar sobre tres errores: El primero marcaba que no se encontraban algunas carpetas y archivos, este problema fue sencillo de resolver, solo se crearon las rutas y el archivo que no se encontraba y los mensajes de inconformidad disminuyeron. El segundo error fue un poco m as dif cil de resolver, y era vital resolver, ya que la conguraci on hab a llegado lejos, pero aun as no estaba terminada. En este caso el error ten a que ver un mal funcionamiento de una funci on que correspond a a otro script de conguraci on que se llamaba, la verdad poco ten amos que hacer. Por lo que despu es de intentar resolver y sin tener exito; se decidi o desinstalar el servicio WMS y volverlo a instalar. Al correr el comando para la conguraci on de nuevo este problema quedo atr as. El tercer error, mostraba el siguiente mensaje: ERROR The following conguration macros appear to contain default values that must be changed before Condor will run. These macros are: allow write (found on line 215 of /opt/condor-c/etc/condor cong) at line 241 in le condor cong.cpp Aunque ya para estos momentos la conguraci on era satisfactoria el servicio Condor no se hab a levando, y se mostraba como correcta la conguraci on pero autom aticamente se hab a saltado el problema para conseguirlo. Por lo que tarde que temprano probablemente se tendr a que ver la forma de resolver el problema se decidi o poner manos a la obra; y aunque el mensaje no es muy especico, muestra la ruta de un archivo. Se abri o el archivo y una de las l neas estaba comentada, y en la otra era una variable para ser levantada, se intent o ponerle alg un valor; aunque esto no funcion o se opt o por comentar la l nea, y esto arreglo el problema. Al correr el comando para la conguraci on ya la salida no solo fue satisfactoria, si no que se levantaron correctamente todos los m odulos del servicio WMS. En la gura 6.7 podemos se puede observar c omo se van levantando los servicios del WMS, como lo son: el Condor, el JobController, LogMonitor, globus-gridftp-server y BDII; para terminar exitosamente.

6.8.

Instalaci on de glite-WN y glite-CREAM.

Como es posible instalar m as de un servicio en un nodo, a continuaci on se describen los pasos que se siguieron para la instalaci on en una computadora del Nodo Trabajador (glite-WN) y del Elemento de C omputo (glite-CREAM) para la versi on de gLite 3.2. Una vez instalado y congurado el sistema operativo y el servicio ntp cliente, lo siguiente que se realiz o fue obtener los repositorios necesarios para gLite 3.2.

69

6.8. Instalaci on de glite-WN y glite-CREAM.

UAM - Iztapalapa

Figura 6.7: Salida de la conguraci on del servicio WMS. Para empezar a bajar los repositorios accedemos a la carpeta donde se guardan los archivos de repositorios: [root@host]$ cd /etc/yum.repo.d/ Creamos una carpeta: [root@host]$ mkdir otros Movemos el repositorio dag que viene por default a la carpeta que acabamos de crear: [root@host]$ mv dag.repo ./otros/ Obtenemos el repositorio dag de gLite: [root@host]$ wget http://grid-deployment.web.cern.ch/grid-deployment/glite/repos/ 3.2/dag.repo 70

6.8. Instalaci on de glite-WN y glite-CREAM. Para el WN se obtienen los siguientes repositorios:

UAM - Iztapalapa

[root@host]$ wget http://grid-deployment.web.cern.ch/grid-deployment/glite/repos/ 3.2/glite-WN.repo [root@host]$ wget http://grid-deployment.web.cern.ch/grid-deployment/glite/repos/ 3.2/glite-TORQUE client.repo Para el CE se necesitan los repositorios: [root@host]$ wget http://grid-deployment.web.cern.ch/grid-deployment/glite/repos/ 3.2/glite-CREAM.repo [root@host]$ wget http://grid-deployment.web.cern.ch/grid-deployment/glite/repos/ 3.2/glite-TORQUE server.repo [root@host]$ wget http://grid-deployment.web.cern.ch/grid-deployment/glite/repos/ 3.2/glite-TORQUE utils.repo El primer servicio que se debe de instalar es el WN (ya que puede haber problemas de dependencias al instalar antes el servicio CE), para este hay dependencias que no se pueden descargar adecuadamente al querer instalar todo el servicio (esto es un caso particular debido al rewall), por lo que fue necesario instalar ciertos paquetes manualmente. Primero instalamos 2 paquetes mediante yum: [root@host]$ yum install vdt globus essentials [root@host]$ yum install libdcap Hay otros paquetes que tuvieron que ser descargados desde una red diferente a la de la UAM e instalados uno a uno, estos paquetes se obtienen de la siguiente direcci on: http://glitesoft.cern.ch/EGEE/gLite/R3.2/glite-WN/sl5/x86 64/ RPMS.externals/ Una vez descargados se instalan uno por uno (la versi on de los paquetes puede variar a la que se muestra aqu ): [root@host]$ [root@host]$ [root@host]$ [root@host]$ [root@host]$ [root@host]$ [root@host]$ [root@host]$ rpm rpm rpm rpm rpm rpm rpm rpm -ivh -ivh -ivh -ivh -ivh -ivh -ivh -ivh libdcap-tunnel-gsi-2.47.2-0.i386.rpm libdcap-tunnel-gsi-2.47.2-0.x86 64.rpm libdcap-tunnel-krb-2.47.2-0.i386.rpm libdcap-tunnel-krb-2.47.2-0.x86 64.rpm libdcap-tunnel-ssl-2.47.2-0.i386.rpm libdcap-tunnel-ssl-2.47.2-0.x86 64.rpm libdcap-tunnel-telnet-2.47.2-0.i386.rpm libdcap-tunnel-telnet-2.47.2-0.x86 64.rpm

Despu es de esto es posible instalar lo necesario para el WN con una sola sentencia: [root@host]$ yum groupinstall gLite-WN

71

6.8. Instalaci on de glite-WN y glite-CREAM.

UAM - Iztapalapa

Ya que esta instalado el servicio gLite-WN, los dem as paquetes para los servicios de Torque y el CREAM CE se instalan directamente y sin ning un problema de dependencias con el gestor de paquetes yum: [root@host]$ [root@host]$ [root@host]$ [root@host]$ yum yum yum yum install install install install glite-TORQUE client glite-TORQUE utils glite-TORQUE server glite-CREAM

Instalados los paquetes del servicio, copiamos los certicados host a la carpeta correspondiente.

6.8.1.

Conguraci on de glite-WN y glite-CREAM.

Ahora comenzamos con la conguraci on del servicio, para ello creamos la carpeta /home/instalacion/ y dentro de esta un archivo llamado site-info.def que es el contiene los par ametros de conguraci on necesarios para el servicio, los archivos users.conf y groups.conf de igual manera deben ser copiados en esta carpeta. A continuaci on se muestra el contenido del archivo site-info.def para los servicios glite-WN y glite-CREAM: # Nombre del Sitio Grid SITE_NAME=glite-tablet.izt.uam.mx # Hostname del nodo donde se encuentra el servicio CE CE_HOST=tablet8.izt.uam.mx # Ubicaci on del archivo users.conf USERS_CONF=/home/instalacion/users.conf # Ubicaci on del archivo groups.conf GROUPS_CONF=/home/instalacion/groups.conf # Ubicaci on de la lista de Nodos Trabajadores WN_LIST=/home/instalacion/wn-list.conf # Directorio de java JAVA_LOCATION=/usr/lib/jvm/jre-1.5.0-sun # Ubicaci on del servidor Batch, que en este caso se encuentra en el mismo host que el CE BATCH_SERVER=$CE_HOST # Informaci on sobre el sistema Batch: Manejador, Sistema Batch en el CE, Versi on, Carpeta de ejecutable, Carpeta de archivos de registro JOB_MANAGER=pbs # es pbs y no lcgpbs debido a que es CREAM CE CE_BATCH_SYS=pbs 72

6.8. Instalaci on de glite-WN y glite-CREAM.

UAM - Iztapalapa

BATCH_VERSION=torque-2.3.6-2 BATCH_BIN_DIR=/usr/bin BATCH_LOG_DIR=/var/spool/pbs/server_priv/accounting BATCH_SPOOL_DIR=/var/spool/pbs # Estado e Informaci on del CE CREAM_CE_STATE=Special BLAH_JOBID_PREFIX=cream # Contrase~ na para mysql y apel MYSQL_PASSWORD=glite APEL_DB_PASSWORD=APELDB_PWD # Host donde se encuentra APEL APEL_MYSQL_HOST=MON_HOST # Hostname del servicio BDII BDII_HOST=tablet6.izt.uam.mx # Informaci on y arquitectura del Sistema operative del CE CE_OS_ARCH=x86_64 CE_OS=ScientificSL CE_OS_RELEASE=5.4 CE_OS_VERSION=Boron # Caracter sticas de procesador y memoria del host CE CE_CPU_MODEL=COREDUO CE_CPU_VENDOR=Intel CE_CPU_SPEED=1197 CE_MINPHYSMEM=2048 CE_MINVIRTMEM=0 CE_OUTBOUNDIP=TRUE CE_INBOUNDIP=FALSE # Ambientes en los que trabaja el CE CE_RUNTIMEENV= LCG-2 LCG-2_1_0 LCG-2_1_1 LCG-2_2_0 LCG-2_3_0 LCG-2_3_1 LCG-2_4_0 LCG-2_5_0 LCG-2_6_0

73

6.8. Instalaci on de glite-WN y glite-CREAM.

UAM - Iztapalapa

LCG-2_7_0 GLITE-3_0_0 GLITE-3_1_0 GLITE-3_2_0 R-GMA CE_PHYSCPU=2 CE_LOGCPU=2 cl uster batch. CE_SMPSIZE=2 CE_SI00=1 CE_SF00=1 # numero de CPUs en el cl uster batch. # numero de CPUs l ogicos o de trabajos disponibles en el # numero de CPUs l ogicos por nodo.

# Hostname del Elemento de Almacenamiento y punto de montaje DPM_HOST= tablet7.izt.uam.mx SE_LIST= $DPM_HOST SE_MOUNT_INFO_LIST=[tablet7.izt.uam.mx:/home/shared, /home/shared] ACCESS_BY_DOMAIN=false CREAM_DB_USER=creamdb CREAM_DB_PASSWORD=creamdb BLPARSER_HOST=$CE_HOST BLP_PORT=33333 CREAM_PORT=56565 CEMON_HOST=$CE_HOST CE_OTHERDESCR=none CE_CAPABILITY=none # INFORMACI ON DE LA VO # Nombre de la Organizaci on Virtual VOS=vomstest # Nombre de la cola de la VO (podemos escribir el nombre, en este caso se llama igual que la VO) QUEUES=${VOS} VOMSTEST_GROUP_ENABLE=vomstest VO_SW_DIR=/opt/exp_soft ############ # VOMSTEST # ############ VO_VOMSTEST_VOMS_SERVERS=vomss://tablet3.izt.uam.mx:8443/voms/vomstest?/vomstest/ VO_VOMSTEST_SW_DIR=$VO_SW_DIR/vomstest

74

6.9. Instalaci on de glite-LB y glite-BDII.

UAM - Iztapalapa

VO_VOMSTEST_DEFAULT_SE=$DPM_HOST VO_VOMSTEST_STORAGE_DIR=$DPM_STORAGE_DIR/vomstest VO_VOMSTEST_VOMSES=vomstest tablet3.izt.uam.mx 15001 /C=MX/ST=Mexico/L=D.F./ O=UAM/OU=Distribuidos/CN=tablet3.izt.uam.mx vomstest VO_VOMSTEST_VOMS_CA_DN=C=MX/ST=Mexico/L=D.F./O=UAM/OU=Distribuidos/CN=UAM CA Una vez que contamos con el archivo site-info.def, continuamos con la conguraci on del servicio ejecutando el comando yaim, debido a que en este host se est an congurando varios servicios, es necesario ejecutar el comando yaim para que congure todos los servicios a la vez, esto se realiza de la siguiente manera: [root@host]$ yaim -c -s site-info.def -n glite-WN -n glite-TORQUE client -n glite-TORQUE utils -n glite-TORQUE server -n glite-creamCE

Figura 6.8: Salida de la conguraci on de los servicios WN y CREAM-CE.

6.9.

Instalaci on de glite-LB y glite-BDII.

Hecha la instalaci on y conguraci on del Sistema Operativo, continuamos con la conguraci on del servicio ntp cliente, para despu es realizar la instalaci on de los servicios de gLite. Al igual que la PC con los servicios WN y CE, en esta m aquina se instalar on 2 servicios juntos, cabe aclarar que antes de realizar la instalaci on revisamos que los servicios pudieran ser instalados juntos, ya que no todos los servicios pueden convivir en la misma computadora. 75

6.9. Instalaci on de glite-LB y glite-BDII.

UAM - Iztapalapa

Para empezar a bajar los repositorios accedemos a la carpeta donde se guardan los archivos de repositorios: [root@host]$ cd /etc/yum.repo.d/ Obtenemos el repositorio para glite-LB como se muestra a continuaci on: [root@host]$ wget http://grid-deployment.web.cern.ch/grid-deployment/glite/repos/ 3.2/glite-LB.repo Para glite-BDII obtenemos el siguiente repositorio: [root@host]$ wget http://grid-deployment.web.cern.ch/grid-deployment/glite/repos/ 3.2/glite-BDII.repo Bajados los archivos repo, se procede a limpiar el cache de instalaci on con la siguiente instrucci on: [root@host]$ yum clean all Se actualiza el sistema [root@host]$ yum update Se inicia con la instalaci on, primero de glite-LB: [root@host]$ yum install glite-LB [root@host]$ yum install glite-BDII Despu es de instalar los servicios se debe instalar el certicado de host, el cual comparten los dos componentes, por lo que no es necesario instalar un certicado para cada servicio. De igual manera hay que congurar el servicio ntp cliente, as como establecer la contrase na de mysql. En la terminal como root tecleamos la siguiente instrucci on parar entrar a mysql usando la contrase na por default: [root@host]$ mysql -u root mysql Una vez adentro nos aparece la terminal de mysql (mysql>), lista para recibir una orden. Ejecutamos la variable para levantar el password y asignarle el valor que elegimos, tal como se observa a continuaci on: mysql>SET PASSWORD = PASSWORD(glite);

6.9.1.

Conguraci on de glite-LB y glite-BDII.

Este servicio fue instalado en el mismo host en el que se instalo el servicio BDII; por lo que se utiliz o el mismo archivo /home/instalacion/site-info.def para almacenar las variables de conguraci on necesarias para este servicio. # Nombre del sitio SITE_NAME=glite-tablet.izt.uam.mx

76

6.9. Instalaci on de glite-LB y glite-BDII.

UAM - Iztapalapa

# Asignaci on password que usara este servicio para accesar a la base de datos mysql MYSQL_PASSWORD=glite # El nombre del host que contienen el servicio BDII BDII_HOST=tablet6.izt.uam.mx # El nombre host que contiene al BDII site. En este caso el mismo al ser el u nico. SITE_BDII_HOST=tablet6.izt.uam.mx # Nombre del host que contiene el Elemento de Computo CE_HOST=tablet8.izt.uam.mx # Latitud y longitud de la Ciudad de M exico SITE_LAT=19.21 SITE_LONG=99.04 SITE_MAIL=dsgf@libio.izt.uam.mx Como en este caso se instalaron y conguraron dos servicios, la instrucci on para congurar el host fue la siguiente: [root@host]$ yaim -c -s site-info.def -n glite-BDII top -n glite-LB

Figura 6.9: Salida de la conguraci on de los servicio LB y BDII. 77

6.10. Instalaci on de glite-SE.

UAM - Iztapalapa

6.10.

Instalaci on de glite-SE.

De igual manera que en la instalaci on de los dem as servicios, conguramos el servicio ntp cliente, y comenzamos a descargar los repositorios para el servicio de gLite. Accedemos a la carpeta donde se guardan los archivos de repositorios: [root@host]$ cd /etc/yum.repo.d/ Creamos una carpeta: [root@host]$ mkdir otros Movemos el repositorio dag que viene por default a la carpeta que acabamos de crear: [root@host]$ mv dag.repo ./otros/ Obtenemos el repositorio dag de gLite: [root@host]$ wget http://grid-deployment.web.cern.ch/grid-deployment/glite/repos/ 3.2/dag.repo Descargamos los repositorios para el SE: [root@host]$ wget http://grid-deployment.web.cern.ch/grid-deployment/glite/repos/ 3.2/glite-SE dpm mysql.repo [root@host]$ wget http://grid-deployment.web.cern.ch/grid-deployment/glite/repos/ 3.2/glite-SE dpm disk.repo Iniciamos con la instalaci on del servicio, limpiando el cache de instalaci on: [root@host]$ yum clean all Se descargan las u ltimas actualizaciones: [root@host]$ yum update Para este servicio se descargaron dos repositorios, por lo que es decisi on de quien instala los servicios, hacerlo por separado o junto como se muestra en la instrucci on: [root@host]$ yum install glite-SE-dpm disk glite-SE dpm mysql En este caso ocurrieron dicultades para la instalaci on de estos elementos; uno de los problemas que se present o fue en errores de dependencias, en este caso lleg o a marcar dicultades con la dependencia perl-SOAP-Lite, y este problema se resolvi o bajando e instalando manualmente este y otros archivos de la siguiente p agina: http://linuxsoft.cern.ch/dag/redhat/el5/en/i386/dag/RPMS/ Despu es de la instalaci on del servicio, se tiene que instalar el certicado de host, y congurar la contrase na de root para mysql.

78

6.10. Instalaci on de glite-SE.

UAM - Iztapalapa

6.10.1.

Conguraci on de glite-SE.

Empezamos creando el directorio instalacion dentro de la carpeta home, una vez hecho esto se procede a crear un archivo con el nombre site-info.def, adem as tambien a nadimos los archivos users.conf y groups.conf dentro de la carpeta instalacion. A continuaci on se hace un desplegado de todas las variables necesarias que se levantaron para la conguraci on de este servicio: # Nombre del sitio y el mail SITE_NAME=glite-tablet.izt.uam.mx SITE_MAIL=dsgf@libio.izt.uam.mx # Nombre del host que contiene el servicio BDII BDII_HOST=tablet6.izt.uam.mx #Ruta para los archivos que contienen los usuarios y grupos del middleware USERS_CONF=/home/instalacion/users.conf GROUPS_CONF=/home/instalacion/groups.conf # Nombre de la VO VOS="vomstest" QUEUES="vomstest" # Asignacion del password para la base de datos MYSQL_PASSWORD="glite" #Nombre del host que contiene al SE (Elemento de Almacenamiento) DPM_HOST="tablet7.izt.uam.mx" DPMPOOL=Permanent # Carpeta donde se el sistema de archivos DPM DPM_FILESYSTEMS="$DPM_HOST: /home/shared" # Nombre del usuario dado de alta en glite en USERS_CONF DPM_DB_USER="user000" DPM_DB_PASSWORD="glite" DPM_DB_HOST=$DPM_HOST DPMFSIZE=200M DPM_INFO_USER=dpm DPM_INFO_PASS=glite SE_LIST="$DPM_HOST" SE_ARCH="multidisk" RFIO_PORT_RANGE="20000 25000" SE_GRIDFTP_LOGFILE=/var/log/dpm-gsiftp/dpm-gsiftp.log 79

6.10. Instalaci on de glite-SE.

UAM - Iztapalapa

############ # VOMSTEST # ############ VO_VOMSTEST_VOMS_SERVERS=vomss://tablet3.izt.uam.mx:8443/voms/vomstest?/vomstest/ VO_VOMSTEST_SW_DIR=$VO_SW_DIR/vomstest VO_VOMSTEST_DEFAULT_SE=$DPM_HOST VO_VOMSTEST_STORAGE_DIR=$DPM_STORAGE_DIR/vomstest VO_VOMSTEST_VOMSES=vomstest tablet3.izt.uam.mx 15001 /C=MX/ST=Mexico/L=D.F./ O=UAM/OU=Distribuidos/CN=tablet3.izt.uam.mx vomstest VO_VOMSTEST_VOMS_CA_DN=C=MX/ST=Mexico/L=D.F./O=UAM/OU=Distribuidos/CN=UAM CA

Con el archivo de conguraci on listo ejecutamos el comando yaim para aplicar la conguraci on del servicio: [root@host]$ yaim -c -s site-info.def -n glite-SE-dpm disk -n glite-SE dpm mysql

Figura 6.10: Salida de la conguraci on del servicio SE. Al momento de correr este comando para la conguraci on se presentaron algunos problemas, uno de ellos fue con el mysql (provoacada por la variable MYSQL PASSWORD); ya que no se hab a congurado la contrase na root de mysql antes de ejecutar el comando yaim. 80

6.10. Instalaci on de glite-SE.

UAM - Iztapalapa

Por ultimo marcaba un error en dpm disk debido a que en las variables no se hab a puesto en que parte se iban a alojar los archivos del sistema, se arreglo poniendo en la variable DPM FILESYSTEMS=$DPM HOST: /home/shared y claro, creando la carpeta que se indica. Este fue uno de los servicios que m as problemas present o para su conguraci on, por lo que paulatinamente se fueron eliminando los errores en base a la informaci on que iba arrojando el script, a pesar de que al nal el resultado se muestra como exitoso aun existen problemas relacionados con credenciales: send2nsd: NS002 - send error : Bad credentials, lo cual se revisar a con la continuaci on de este proyecto.

81

ndice A Ape

Instalaci on y conguraci on de Ubuntu.

Para la instalaci on de Ubuntu es necesario que la PC arranque desde el CD-ROM, en caso de que esto no ocurra, se puede realizar la conguraci on adecuada desde el BIOS, una vez que la PC ha iniciado desde el CD-ROM, lo primero que aparece es la opci on de elegir el idioma, despu es al ser un livecd aparecen varias opciones, de las cuales seleccionamos la opci on de Instalar Ubuntu. Al cargar el sistema la primera ventana que aparece es nuevamente la de idioma, se puede cambiar el idioma si es que no se selecciono la primera vez el adecuado o simplemente seleccionar Adelante. Elegimos la zona horaria d onde estamos y continuamos. En la siguiente ventana escogemos la distribuci on adecuada del teclado. Despu es el proceso de instalaci on comienza a revisar el o los discos duros instalados para crear las particiones. Depende de si hemos preparado las particiones con anticipaci on o debemos crearlas. Para la instalaci on de Ubuntu por lo menos debe haber dos particiones una swap que es para intercambio de memoria y otra raiz /, donde se instalan todos los archivos del sistema.

Figura A.1: Comenzando Particionamiento. Para el particionamiento tenemos tres opciones: La m as f acil es Instalado junto a los otros, eligiendo entre ellos al arrancar el equipo en la cual el sistema se encarga autom aticamente de hacer o modicar las particiones. Borrar y usar el disco entero, en donde el sistema tambi en congura las particiones. Especicar particiones manualmente (avanzado), que es la que vamos a utilizar porque nos da m as libertad para escoger el formato de las particiones, tama no y el lugar, es m as complicada pero necesaria ya que en nuestro caso se tiene que instalar m as de un sistema operativo en la maquina y es necesario dejar espacio libre. Se selecciona esta y se da click en Adelante. Dependiendo de los discos duros que se tenga y de la capacidad de estos aparecer a la informaci on, en este caso se instalara Ubuntu en particiones creadas tomando en cuenta que no se debe de modicar la partici on existente de para el sistema Windows. Se crearon dos particiones: La partici on / ra z con formato ext3, en esta partici on de guardaran los archivos del sistema. La partici on swap, la cual sirve para intercambio de memoria del sistema. 82

UAM - Iztapalapa

Figura A.2: Men u de Particionamiento. Una vez que creamos y montamos las particiones adecuadamente seguimos con el proceso de instalaci on. Ubuntu tiene la opci on de importar datos y conguraci on de cuentas de usuario de otros sistemas operativos, a esta ventana no le haremos mayor caso, simplemente continuamos. La siguiente opci on es para crear la cuenta con la que se iniciar a sesi on en Ubuntu, aqu se pedir a el nombre de usuario, nombre para inicio de sesi on, contrase na y nombre del equipo. A diferencia de otras distribuciones Linux en donde se tiene que especicar la contrase na para el usuario root que llevar a la administraci on del sistema y crear un usuario aparte, en Ubuntu el usuario que se crea tiene por default privilegios de administrador. Una vez que damos los datos para inicio de sesi on la ventana que sigue es un resumen de la instalaci on que se llevar a a cabo, si estamos de acuerdo damos click en Instalar.

A.0.2.

Conguraci on de la red.

Para los sistemas basados en Debian que es el caso de Ubuntu existen herramientas para congurar la red, pero no existe una por default como en el caso de los sistemas Red Hat, as que de forma general la conguraci on se realiza por medio de archivos. El archivo que necesitamos modicar para la conguraci on se llama interfaces y se encuentra en la carpeta /etc/network/, a diferencia de los sistemas Red Hat en los que cada interfaz tiene su archivo de conguraci on, en el archivo interfaces se conguraran todas las interfaces de red que tenga el sistema, por lo tanto cada interfaz debe de tener delimitada su secci on de conguraci on para que no existan problemas entre una y otra. Para este archivo cada l nea 83

UAM - Iztapalapa corresponde a un par ametro y tienen el formato: par ametro valor, como se puede ver en el siguiente ejemplo: iface eth0 inet static address 192.168.0.194 netmask 255.255.255.0 network 192.168.0.0 gateway 192.168.0.251

A.0.3.

Asignaci on del hostname.

Para asignarle el nombre al host, s que es no se asigno el adecuado durante la instalaci on, se puede hacer de dos formas, la primera mediante el comando: [root@host]$ hostname NOMBRE La desventaja que existe con esta opci on es que el cambio no es permanente, cuando se apague o reinici e la maquina regresar a al nombre anterior, la otra opci on que existe si es permanente y consiste en modicar un archivo de conguraci on: /etc/hostname

A.0.4.

Archivo hosts.

En el archivo hosts conguramos el nombre o nombres con los que el equipo ser a reconocido, de igual manera en este mismo se pueden especicar los nombres de los dem as equipos de red para que no s olo sean reconocidos por su direcci on IP sino tambi en mediante un nombre. Para el caso de Ubuntu el archivo se encuentra en la carpeta: /etc/

A.0.5.

Archivo resolv.conf.

En este archivo conguramos la direcci on IP de nuestro o nuestros servidores de nombres (DNS), la conguraci on se hace de la forma: nameserver @IP. El archivo resolv.conf se encuentra en la carpeta: /etc/.

A.0.6.

Reinicio del servicio de red y comprobaci on de su funcionamiento.

Una vez que se han congurado los archivos para dar de alta el servicio de red, es necesario reiniciar este servicio, y hacer pruebas para vericar que est a funcionando adecuadamente, a continuaci on se describe como hacer esto: Para reiniciar el servicio: [root@host]$ /etc/init.d/networking restart En las nuevas versiones de Ubuntu tambi en es posible utilizar: 84

UAM - Iztapalapa

[root@host]$ service networking restart Para comprobar que los cambios en la conguraci on de red fueron hechos se puede utilizar: [root@host]$ ifconfig Lo anterior mostrar a los par ametros actuales de la tarjeta de red. Una vez que la conguraci on est a hecha se puede comprobar la conexi on por medio del comando ping: [root@host]$ ping <direcci on IP/nombre host> En caso de que la conexi on sea adecuada se observar a un mensaje mostrando que todos los paquetes enviamos fueron recibidos con exito.

85

ndice B Ape

Instalaci on y conguraci on de Scientic Linux.

El sistema operativo que se instal o en las m aquinas fue Scientic Linux SL, en sus versiones 4.8 de 32 bits y 5.4 de 64 bits, se utilizaron estas 2 versiones debido a que como ya se mencion o anteriormente algunos de los servicios de gLite no est an disponibles para la versi on de 64 bits, por lo que es necesario instalarlos en sistemas de 32 bits. En las maquinas con sistemas de 32 bits se instalaron paquetes de gLite 3.1, mientras que para las computadoras con SL de 64 bits se instalaron servicios de gLite 3.2. El proceso de instalaci on del sistema operativo que se describe a continuaci on se realiz o para la versi on SL 5.4 de 64 bits, pero los pasos son pr acticamente los mismos para la versi on SL 4.8 de 32 bits, as que se puede seguir el siguiente procedimiento sin ning un problema para ambas versiones. Para comenzar el proceso de instalaci on de Scientic Linux (SL) es necesario que la PC arranque desde el CD-ROM, en caso de que esto no ocurra, se puede realizar la conguraci on adecuada desde el BIOS. Una vez que se inicia desde el CD-ROM los pasos para la instalaci on son los siguientes: Aparece la pantalla inicial de booteo, en la cual si es necesario podemos especicar algunas opciones de arranque del sistema. Presionamos Enter para que comience la carga del sistema operativo, esto debido a que la distribuci on que utilizamos es live, es decir, el sistema operativo puede iniciar desde el CD-ROM sin necesidad de instalarlo, aunque una vez cargado nos da la posibilidad de instalarlo al Disco Duro de la PC, que en nuestro caso es lo que realizaremos.

Figura B.1: Iniciar la instalaci on de SL. Mientras se inicia el sistema se solicitan algunos datos como son la distribuci on de teclado que utilizamos, as como la contrase na de root para la sesi on live, con la posibilidad de cambiarla o mantenerla al momento de hacer la instalaci on. 86

UAM - Iztapalapa Una vez que termina la carga del sistema aparece la ventana de inicio de sesi on, para comenzar con la instalaci on del Sistema Operativo iniciamos sesi on como usuario root. Seleccionamos la opci on de Instalaci on de Sistema Operativo al disco duro en el menu principal de la siguiente manera System Administration -> Install LiveCD/DVD <-. Aparecer a una ventana con algunas opciones de conguraci on, y la opci on de comenzar con la instalaci on, si es necesario en este momento se pueden crear las particiones necesarias para el sistema y despu es de ello se comenzar con la instalaci on.

Figura B.2: Ventana inicial de la instalaci on de SL. Al iniciar con el proceso de instalaci on nos pide que seleccionemos el disco duro y/o la partici on en donde se instalar a el sistema (en este punto ya no se pueden modicar las particiones) as como el sistema archivos con el que se formater a, elegimos partici on y continuamos. Lo anterior tambi en se realiza para la partici on que funcionar a como intercambio del sistema (swap). Lo siguiente que aparece es la opci on del Grub, seleccionamos instalarlo y continuamos con la contrase na de root. Al nal se muestra una ventana con las opciones de instalaci on, al dar .aceptarse comienza la copia y conguraci on de los archivos necesarios, una vez terminado el proceso de instalaci on del Sistema Operativo, reinciamos la computadora y quitamos el CD para que arranque el sistema desde el Disco Duro.

Figura B.3: Opciones de la instalaci on de SL. Concluida la instalaci on del Sistema Operativo continuamos con la conguraci on de los servicios de Red. 87

UAM - Iztapalapa

B.0.7.

Conguraci on de la Red.

Ya que se realiz o la instalaci on del sistema operativo, se congura la red para que los equipos puedan tener comunicaci on entre ellos as como acceso a internet (en caso de que se cuente con el servicio). Debido a que la distribuci on de Scientic Linux est a basada en Red Hat, la conguraci on se puede realizar de dos maneras, por medio del programa de conguraci on setup o directamente mediante los archivos de conguraci on. Por medio de la herramienta setup. Para abrir la herramienta se teclea desde una terminal: [root@host]$ setup Con lo cual aparecer a una ventana para seleccionar el servicio a congurar y a partir de ah los pasos a seguir son los siguientes: 1. Seleccionar Conguraci on de la red 2. Seleccionar Editar par ametros de dispositivo 3. Elegir la interfaz que queremos congurar (si se tiene m as de una tarjeta de red), en este caso solo est a la tarjeta eth0. 4. Teclear el nombre de la interfaz, deshabilitar uso de DHCP, escribir la direcci on IP est atica, la M ascara de Red, la direcci on IP del Gateway, el Servidor primario DNS y en caso de ser necesario el servidor secundario DNS. 5. Guardar los cambios y terminar la herramienta. Por medio de los archivos de conguraci on. El setup es una herramienta que nos ayuda a congurar los servicios, al nal esta herramienta es la que se encarga de hacer las modicaciones necesarias a los archivos de conguraci on, pero si te tiene el conocimiento suciente se puede congurar la red directamente por medio de estos archivos. Los archivos de conguraci on de red se encuentran en la carpeta: /etc/syscong/network-scripts/. El archivo que debemos congurar se llama: ifcfg-eth#, donde # es un numero que depende de la tarjeta que red que se quiere congurar, en esta caso solo se encuentra la tarjeta eth0 y por tanto su archivo de conguraci on es: ifcfg-eth0. Para congurar el archivo se abre con cualquier editor de texto (por ejemplo vim o gedit) y se modican o agregan los par ametros deseados, que consisten en l neas de texto con la forma: PARAMETRO=valor, como se puede ver en los siguientes ejemplos a continuaci on: IPADDR=192.168.0.3 NETMASK=255.255.255.0 NETWORK=192.168.0.0

88

UAM - Iztapalapa

B.0.8.

Archivo hosts.

En este archivo conguramos el nombre o nombres con los que el equipo ser a reconocido en la red, de igual manera en este mismo se pueden especicar los nombres y direcciones IP de los dem as equipos de red para que no s olo sean reconocidos por su direcci on IP sino tambi en mediante un nombre. Para el caso de los sistemas basados en Red Hat el archivo hosts se encuentra en la carpeta: /etc/syscong/network-scripts/

B.0.9.

Archivo network.

En este archivo conguramos la direcci on IP del que ser a nuestro GATEWAY as como el nombre de nuestro host, es decir, nuestro hostname, la conguraci on se hace de la forma: PARAMETRO=valor. Para el caso de los sistemas basados en Red Hat el archivo network se encuentra en la carpeta: /etc/syscong/.

B.0.10.

Archivo resolv.conf.

En este archivo conguramos la direcci on IP de nuestro o nuestros servidores de nombres (DNS), la conguraci on se hace de la forma: nameserver @IP. Para el caso de los sistemas basados en Red Hat el archivo resolv.conf se encuentra en la carpeta: /etc/.

B.0.11.
red.

Reinicio del servicio de red y comprobaci on de su funcionamiento.

Despu es de la conguraci on de las interfaces de red es necesario iniciar o reiniciar el servicio de [root@host]$ service network restart [root@host]$ /etc/init.d/network restart Para comprobar que los cambios en la conguraci on de red fueron hechos se puede utilizar: [root@host]$ ifconfig Que mostrar a los par ametros actuales de la tarjeta de red. Una vez que la conguraci on est a hecha en todas las maquinas se puede comprobar la conexi on entre ellas por medio del comando ping: [root@host]$ ping <direcci on IP/nombre host> En caso de que la conexi on sea adecuada se observar a un mensaje mostrando que todos los paquetes enviamos fueron recibidos con exito.

89

Conclusiones.
La tecnolog a Grid ha sido una herramienta de mucha ayuda que ha venido a dar una soluci on a distintos problemas de c omputo, ya que permite que una organizaci on que no cuenta con la infraestructura necesaria para ejecutar programas complejos, puede implementar junto con otras instituciones un sistema Grid que pueda satisfacer sus requerimientos computacionales, sin importar la ubicaci on geogr aca de cada una de estas instituciones. El middleware gLite es una herramienta que nos ayuda para la implementaci on de una grid, como se mencion o no esta construida desde cero, sino que hace uso de software de otros proyectos, dentro de los cuales destaca el proyecto Globus considerado como el est andar de la tecnolog a Grid. Para el desarrollo de este proyecto se tuvo que investigar la arquitectura y funcionamiento de gLite para poder llegar implementarlo, y debido a que es un sistema bastante completo fue dif cil enfocarse en un solo servicio, ya que si hac amos esto no se avanzaba con otros servicios que tambi en eran necesarios, por lo que se opt o por revisar los servicios de una manera m as general. Una vez que se estudio gLite se comenz o con la instalaci on de los servicios por medio de repositorios, primero de la versi on de gLite 3.1, pero debido a que algunos servicios ten an problemas con dependencias que no se pod an cumplir las dicultades aparecieron enseguida y no se alcanzo el objetivo de instalar los servicios, por lo que fue necesario actualizar la versi on de glite 3.2, esto fue un gran cambio, ya que la versi on reciente necesita un Scientic Linux de 64 bits, por lo que tambi en cambiamos de versi on de S.O y arquitectura de maquinas. Excepto para el servicio central el Workload Manager Service (WMS), del cual aun no se encuentran los repositorios y esta en un S.O. de 32 bits. El principal obst aculo se debi o a que la versi on del S.O. En gLite 3.1 ya era un poco atrasada por lo cual se deja de actualizar. Una vez instalados los servicios, lo que ven a era levantar cada uno de modo que se viera con los dem as; hasta aqu no sab amos la importancia de tener una Autoridad Certicadora, aunque era posible iniciar la conguraci on de cada servicio uni endonos a una VO (Gilda) ya existente, de hecho la primera instalaci on se hizo de esta manera, pero al pertenecer a Gilda ten amos que solicitar certicados, esto implicaba hacer una solicitud del tipo de certicado y de la validez. Lo que nos pon a en una posici on de dependencia y de ir al paso conforme nos fueran llegando los certicados. Por lo que se opt o por generar nuestra propia CA. Teniendo nuestra propia CA se cuenta con muchas ventajas, la principal es que puedes continuar con la conguraci on de los servicios, y por consiguiente la comunicaci on entre estos es segura. Adem as permite libertad de administrar tu propia VO, ya que no es necesario pertenecer a una VO ya existente. En gLite la seguridad es muy importante, ya que al compartir recursos de computo con usuarios que no pertenecen siquiera a la misma instituci on se deben tomar medidas para que s olo los utilicen quienes tengan autorizaci on, como se explic o los certicados ayudan a controlar esta seguridad, pero dentro de los servicios de gLite no existe uno que nos ayude a crear los certicados, solo se menciona que debemos de solicitarlos a una CA v alida. En nuestro caso al ser una grid de prueba pensada para trabajar de forma independiente el solicitar los certicados a una CA se descarto, pero al intentar implementar nuestra propia CA o al menos crear nuestros certicados, nos encontramos con muchas complicaciones, ya que pr acticamente no encontramos informaci on sobre los requerimientos que tenia que cumplir una CA para gLite, y tampoco existen muchas opciones de software para una CA, y sin certicados no se pod a avanzar con la conguraci on de los servicios. Afortunadamente nos encontramos con gnoMint que 90

UAM - Iztapalapa result o ser un software sencillo para creaci on y administraci on de certicados, y hasta el momento las pruebas que se han realizado con certicados hechos con esta herramienta han sido satisfactorias. En la conguraci on algunos servicios fueron m as nobles que otros, con algunos bast o con crear su certicado e instalarlo, adem as de levantar algunas variables, como fue el caso del LB y BDII. Pero otros servicios como WMS, CE y SE no lo fueron, a pesar de seguir los manuales, estos no cubr an en la totalidad la explicaci on para algunas variables, solo se ten an los mensajes de fallo y la causa, en base a esto se busc o en el archivo site-info.def que viene con la instalaci on de los servicios, en la p agina principal de gLite, y en la web; e incluso revisando el script de conguraci on para conocer mas sobre el mensaje de error. Aqu fue muy necesario ser pacientes y estudiar el problema, ya que algunos de estos errores se solucionaron solo con crear una carpeta, un archivo, o cambiando permisos de lectura/escritura. Al nal de este proyecto podemos decir que gLite es un software muy completo para la implementaci on de una Grid, esta compuesto de servicios bien estructurados en donde cada uno tiene su funci on espec ca y posee una comunicaci on adecuada gracias a una serie de protocolos de red que garantizan rapidez y seguridad. En un principio no fue f acil esta tarea, pero conforme se avanz o en el proyecto se fueron obteniendo resultados favorables, que indicaron que se ha ido por un buen camino.

91

Bibliograf a.
Burke, Stephen et a l, GLITE 3.1 USER GUIDE - MANUAL SERIES, versi on 1.2, 2009 (2010) Logging and Bookkeeping - ADMINISTRATORS GUIDE, versi on 1.1.6, 2010 Cuttone, Filippo; Di Stefano, Antonella; Morana, Giovanni, Designing a dependable job submission systeam in gLite, 2010 Berkeley Database Information Index V5, 2010 Pacini, F., EGEE Users Guide - WMS SERVICE, versi on 0.2, 2006 Maraschini, A., EGEE Users Guide - WM PROXY SERVICE, versi on 0.2, 2006 Foster, Ian, What is the Grid? A Three Point Checklist, 2002 Foster, Ian; Kesselman, Carl; Tuecke Steven, The Anatomy of the Grid - Enabling Scalable Virtual Organizations, 2001 David, Sistema libre para la gesti MAR IN CARRENO, on de una autoridad de certicaci on X.509: gnoMint, 2009 Magoul` es, Fr ed eric; Pan, Jie; Tan, Kiat-An; Kumar, Abhinit Kumar, Introduction to Grid Computing, 2009 https://twiki.cern.ch/twiki/bin/view/DefaultWeb/WebHome https://grid.ct.infn.it/twiki/bin/view/GILDA/AuthenticationAuthorization http://www-numi.fnal.gov/oine software/srt public context/GridTools/docs/jobs tutorial.html http://egee-uig.web.cern.ch/egee-uig/production pages/InstallUI.html http://grid.pd.infn.it/cream/eld.php?n=Main.HomePage http://glite.web.cern.ch/glite/ http://www.aragrid.es/wiki/index.php/T ecnica http://code.google.com/p/one-click-deployable-grid-infraestructure/

92