Herramientas para el monitoreo de componentes (HARDWARE)

Ganglia es una herramienta de monitoreo en tiempo real para clusters y grids. Ganglia utiliza la misma base de datos desarrollada para MRTG (Multi Router Traffic Grapher) basado en mecanismos de actualización de registros round-robin.

El primer prototipo de Ganglia aparece con la Versión 1.0 en el año 2000, con las siguientes características:

• Demonios escritos en Perl.
• Introducción de subprogramas conocidos como axons, que permiten el almacenamiento de los datos resultantes de la comunicación multicast en memoria y los comparten a través de conexiones lógicas (sockets).
• Inclusión de una interfaz Web que se comunica con los axons para recuperar la información.

La Versión 2.x aparece en el año 2001. Esta versión es más estable y su código fue escrito en lenguaje C. Los axons y los demonios de Perl originales se incluyeron dentro de un proceso conocido como gmond. Esta implementación fue diseñada bajo el concepto de P2P (Peer to Peer) utilizando XML (eXtensible Markup Language) y XDR (XML Data Reduce).

Desde el año 2002, el desarrollo de Ganglia está a cargo del grupo SourceForge, quienes hicieron posible que su distribución sea multiplataforma: Linux (i386, 64, SPARC, ALPHA), FreeBSD, Windows, AIX, IRIX, MacOS X, y otros.

La última versión de Ganglia (Versión 2.5) publicada en Enero de 2002, se desarrolló bajo el modelo cliente-servidor y está compuesta de cuatro partes fundamentales, que a continuación se describen:

• El demonio de monitoreo: gmond, el cual debe ser instalado en cada nodo del cluster.
• El backend para la recolección de los datos, el demonio: gmetad. Instalado únicamente en el nodo de administración.
• La interfaz Web, o mejor conocido como frontend. Esta debe ser instalada en el nodo de administración únicamente.
• Los datos se transmiten utilizando XML y XDR mediante una conexión TCP y multicast. Esto se logra a través de una clase creada con Phyton, para ordenar y clasificar los datos, y desempeñar funciones de comunicación, como la transmisión y recepción de los datos.

Además de los componentes fundamentales, existen dos herramientas bajo línea de comandos. La primera: gstat, la cual provee un medio de comunicación para realizar consultas al demonio gmond, y permite crear reportes del estado del cluster. La segunda: gmetric, que permite monitorear de manera sencilla las métricas de los equipos, además de las predefinidas por Ganglia, como: número de procesadores, memoria utilizada, velocidad del CPU entre otros.

El comando gmetric trabaja en conjunto con el demonio crond, permitiendo realizar un itinerario de tareas; es decir, realizar tareas a cierta hora en un día determinado.

Ganglia provee un ambiente de ejecución único mediante la utilización del comando gexec, emplea el uso de 3 hilos de ejecución, uno para las entradas estándar (stdin), uno para las señales del sistema, y otro para las entradas y salidas de error (stderr). gexec permite ejecutar comandos en el cluster de manera transparente y redireccionar las salidas por medio de las entradas y salidas estándar (stdin, stdout y stderr).

[SUBIR]

---

CONDOR

Condor es un producto de Condor Research Project de la Universidad de Wisconsin, Madison y desarrollado por el Departamento de Ciencias de la computación hace ya más de 10 años. Condor es un software de código abierto.

Cientos de organizaciones en la industria, el gobierno de EEUU y las universidades utilizan Condor para establecer ambientes de cómputo que superan el rango de cientos de estaciones de trabajo.

Condor es un sistema de administración especializado para monitorear y satisfacer necesidades computacionales en trabajos de cómputo intensivos. Este sistema provee un mecanismo de manejo de colas, políticas de planificación, esquema de prioridades, monitoreo de recursos, y administración de los mismos.

Los usuarios realizan peticiones a Condor, que luego son colocadas en una cola, en donde mediante un proceso de selección se establece en dónde y cuándo se ejecutarán.

Entre las funcionalidades más importantes de Condor, se puede mencionar:

• Directiva ClassAds: Esta directiva provee un marco de trabajo flexible y expresivo para determinar si solicitudes de acceso a recursos (trabajos) coinciden con los recursos ofrecidos por el sistema (computadores).
• Entrega distribuida: Condor no establece un computador central que reciba y entregue solicitudes de recursos (tareas). Las tareas se entregan desde varios computadores, donde cada uno posee su propia cola de trabajos.
• Prioridades de usuario: Los administradores pueden asignar prioridades a los usuarios mediante un mecanismo que habilita una política de compartición justa (fair share), orden estricto o una combinación de políticas.
• Prioridades de tareas: El orden de ejecución de las tareas de los usuarios se controla mediante asignación de prioridades.
• Dependencia de tareas: Algunas tareas no son independientes por tal motivo si existe un conjunto de tareas relacionadas se requiere un orden de inicialización de las tareas. Por ejemplo una tarea X se inicia solo si una tarea Y ha completado el trabajo que estaba realizando.
• Soporte de tareas simultáneas: Permite manipular tareas de tipo serial y paralelas con la incorporación de PVM y MPI.
• Puntos de verificación (checkpoints) y migración de tareas: Condor puede realizar puntos de verificación de manera transparente; es decir, proporciona la ilusión que la tarea se ejecuta normalmente. Un punto de verificación es como tomar una imagen instantánea (snapshot) del estado de la tarea. La tarea puede continuar su ejecución desde el punto de verificación. Un punto de verificación habilita la migración transparente de tareas desde un nodo a otro. Condor coloca un punto de verificación de una tarea, cuando éste programa los recursos a ser asignados a diferentes tareas o cuando un recurso es devuelto a su propietario. Mediante los puntos de verificación y la migración de tareas se provee una forma de tolerancia a fallos, que garantiza la utilización del tiempo de computación acumulado para una tarea; es decir, reduce las pérdidas ante eventos de fallos del sistema tales como apagado inadecuado o deficiencias del hardware.
• Suspensión y reanudación de tareas: Condor puede preguntar al sistema operativo si puede suspender o reanudar una tarea cuando se requiera. Para poder desempeñar estas tareas Condor utiliza reglas basadas en políticas.
• Autenticación y autorización: Condor permite tener autenticación de red utilizando una gran variedad de mecanismos; por ejemplo, Kerberos e ITU-T X.509, lo que permite la inclusión de certificados digitales basados en llave pública.
• Plataformas heterogéneas: Condor tiene soporte para sistemas Linux, UNIX y Windows.
• Grid computing: Condor incorpora funcionalidades basadas encomputación grid. Condor incluye el software necesario para recibir tareas de otros clusters, supercomputadores y sistemas distribuidos utilizando el toolkit Globus. Condor puede entregar tareas mediante recursos administrados por otros sistemas de planificación tales como PBS utilizando Globus.

---

PBS

PBS (Portable Batch System) es un sistema flexible de balanceo de carga y planificación de tareas, inicialmente fue desarrollado para administrar recursos computacionales de la NASA. PBS ha sido el líder en la administración de recursos y considerado el estándar de facto para los sistemas de planificaciónes bajo sistemas Linux.

E n el año de 1986 la NASA, junto al Centro de Investigación Ames desarrolló el primer sistema de manejo de colas para el sistema operativo UNIX, denominado NQS (Network Queueing System). NQS en pocos años se convirtió en un estándar de facto para el manejo de colas por lotes. Una vez que los sistemas paralelos aparecieron, el sistema NQS se volvió inadecuado para manipular requerimientos complejos de administración de recursos.

La NASA lideró un intento por recopilar los requerimientos para un sistema de administración de recursos de siguiente generación. Estos requerimientos y funcionalidades de un sistema para administración de recursos fueron adoptados por la IEEE (Institute of Electrical and Electronics Engineers) en el estándar POSIX 1003.2d. Luego, en el año de 1999 la NASA diseñó un sistema que cumple con los requerimientos del estándar de la IEEE. Este sistema se denominó PBS el cual reemplazó rápidamente a NQS en los supercomputadores tradicionales y sistemas tipo servidor.

La empresa Veridian diseño el sistema PBS para la NASA, y luego, en Marzo de 2003, desarrolló una solución integral de administración de balanceo de carga, conocida como PBS Pro, cuya licencia fue adquirida por la empresa Altair Engineering, Inc.

Actualmente existen dos versiones de PBS: una versión antigua de código abierto Altair OpenPBS y la versión comercial Altair PBS Pro. Actualmente OpenPBS y PBS Pro se incluyen en algunos toolkits para la instalación automática de clusters. PBS Pro provee algunas funcionalidades y beneficios para los administradores del cluster.

Las características más importantes del sistema PBS son:

• Múltiples interfaces de usuario: Proveen una interfaz gráfica de usuario para realizar peticiones por lotes y ejecución de tareas.

• Listas de seguridad y control de acceso: El administrador puede permitir o denegar el acceso al sistema PBS basándose en el nombre de usuario, grupo, nodo o dominio de red.

• Registro de tareas: logs detallados de las actividades del sistema mediante el análisis de utilización por usuario, por grupo y por nodo.

• Soporte de tareas paralelas: Permite la utilización de librerías de programación paralela como MPI, PVM, y HPF. Se puede planificar la ejecución de aplicaciones sobre un computador de un sólo procesador o mediante la utilización de múltiples computadores.

• Monitoreo del sistema: Mediante una interfaz gráfica permite realizar un monitoreo completo del ambiente distribuido.

• Soporte para grids: Provee tecnología para grids computacionales y la integración del toolkit Globus.

• API de desarrollo: Permite desarrollar aplicaciones que integran PBS como una de sus herramientas para requerimientos de balanceo de carga.

• Nivel de carga automático: Provee diversas formas de distribuir la carga en los computadores que conforman el cluster, basados en la configuración de hardware, disponibilidad de recursos, actividad del teclado y el manejo de políticas locales.

• Distributed clustering: Permite la disponibilidad de recursos de clusters y otros sistemas distribuidos en una red WAN.

• Ambiente común de usuario: Ofrece al usuario una visión común de las tareas entregadas y solicitadas, el estado del sistema y seguimiento de tareas.

• Priridad de tareas: Permite a los usuarios especificar prioridades para la asignación de recursos y ejecución de sus tareas.

• Disponibilidad para diferentes plataformas: Permite el soporte de Windows 2000 y XP, junto con la mayoría de versiones de UNIX y Linux, desde estaciones de trabajo y servidores hasta supercomputadores.