CLUSTERS :: Definiciones
Clusters | Herramientas de Instalación Automáticas de Clusters | Herramientas de Desarrollo | Adminsitración y Planificación de Tareas


Administración y Planificación de Tareas


Existen algunas alternativas de herramientas de software que permiten la administración, monitoreo y balanceo de carga computacional en los clusters de computadores personales. Estas tareas específicas pueden ser administradas con herramientas bien conocidas, tales como: C3 (Cluster Command & Control) y Ganglia, que presentan funcionalidades para la administración y monitoreo; Condor y PBS (Portable Batch System), que permiten la planificación, asignación de recursos y tareas.


 

HERRAMIENTAS PARA LA ADMINISTRACIÓN DE CLUSTERS

La operación de clusters requiere de un manejo adecuado de los recursos asociados. Los recursos del cluster deben ser administrados adecuadamente para que el administrador invierta la menor cantidad de tiempo en detectar, investigar y recuperar fallos de hardware y software, y de este modo definir posibles medidas de contingencia y tratar que el sistema esté libre de errores. A su vez, estos pasos permiten la adaptabilidad a los requerimientos y cambios constantes que se presentan en la manipulación de tecnologías cluster, en cuanto se refiere al
hardware, software y al uso de ciertos patrones de diseño.

El administrador de un cluster debe tomar en cuenta algunos aspectos, una vez que se ha completado la instalación de los recursos básicos de hardware y software. Estos aspectos incluyen la configuración e instalación de un sistema de archivos universal, la configuración y administración de recursos mediante herramientas implementadas en software; el monitoreo de sus actividades y el registro de cada uno de los eventos generados por la ejecución de cálculos computacionales.

Varios de los sistemas más importantes para la instalación automática de clusters, incluyen herramientas de monitoreo, administración y registro de eventos mediante paquetes de distribución para sistemas Windows y Linux. Entre estos sistemas están OSCAR y Rocks NPACI; ambos sistemas permiten el uso de herramientas de software que tienen propósitos específicos tales como:

• Definición y administración de nodos.

• Administración de colas por lotes (Batch Queue Management).

• Administración de recursos: grupos NIS (Network Information Service), cuotas de disco y CPU.

• Administración de servicios de resolución de nombres : DNS (Domain Name System para clusters)..

• Registro de usuarios para clusters de dimensiones superiores a los 100 nodos.

• Monitoreo de carga.

La administración de clusters, implica tomar medidas preventivas y planificar tareas. La administración implica los siguientes aspectos:

• Registro de eventos.

• Monitoreo o medida del estado de los recursos del cluster.

• Recuperación ante fallos de hardware, software, incluyendo el sistema de archivos.

• Administración del registro de usuarios y grupos de usuarios, de los servicios del cluster (accounting).

• Planificación de tareas y balanceo de carga.

Registro de Eventos
El manejo de logs, o el registro de eventos generados tanto por el kernel del sistema operativo, como por los diferentes servicios que han sido habilitados para el establecimiento de comunicación entre los nodos, se lo puede realizar mediante comandos del sistema operativo Linux para poder visualizar los archivos de logs, o utilizar herramientas de monitoreo tales como:

• LogCheck

• Swatch

• LogSentry

• LogDog

En Linux, el comando más utilizado para visualizar logs es: tail.

Monitoreo y Estado del Cluster
El monitoreo permite conocer si todos los componentes de hardware y software están disponibles y operando de acuerdo a lo esperado. Es decir, debe asegurarse que todos los componentes de hardware estén disponibles durante el arranque del sistema operativo (CPUs, memoria, discos, dispositivos de red y otros), y de igual forma, que todos los servicios de software, tales como: planificadores de tareas, administradores de recursos, y demonios de monitoreo se ejecuten correctamente en el cluster. Entre las herramientas de monitoreso se pueden mencionar:

• Big Brother

• Cluemon

• Ganglia

• Nagios

• PARMON

• Supermon

Recuperación ante fallos
La administración del cluster implica resolver problemas provocados por fallos de hardware y/o software. Los fallos causados por hardware pueden ocasionar que el cluster quede inutilizable.

La recuperación ante fallos a nivel de hardware implica:

1. Aislar los componentes que fallaron para asegurar que no causen unconsiderable impacto en las actividades del cluster.

2. Manejar los componentes de respaldo (backup), para poder hacer reemplazos y minimizar los efectos del fallo.

Los fallos de componentes de software muchas veces no tienen solución o forma de recuperación. Si se considera que el sistema operativo está basado en Linux, la mayor parte de aplicaciones requieren de parches o nuevas versiones para mejorar o recuperarse de errores; sin embargo, este proceso es muy complejo y conlleva mucho tiempo. Por tal motivo, si un componente de software falla lo único que resta por hacer es informar al vendedor, diseñador o desarrollador de la apliación y esperar por las mejoras.

Accounting
Los ambientes Linux ofrecen algunas alternativas para mantener copias de un conjunto de archivos en varios equipos. La forma más común y fácil de administrar las copias de un conjunto de archivos involucra la utilización de una red basada en servicios para la administración de cuentas o registros de usuario. Cuando se emplea esta alternativa, cada computador realiza consultas a un servicio central, el cual maneja la autorización, la autenticación y la información de los usuarios dentro del sistema.

Para la configuración manual de clusters, los servicios más utilizados son NIS (Network Information Service) o LDAP (Lightweight Directory Access Protocol); sin embargo; también se habilitan de forma automática con los toolkits de OSCAR y NPACI Rocks.

Planifiacación de Tareas y Balanceo de Carga
Las actividades de administración y balanceo de carga que son críticas para un entorno cluster son:

• Administrar la disponibilidad de los nodos.

• Configurar atributos de los nodos que sean importantes para balanceo de carga.

• Administrar usuarios y grupos mediante cuotas de disco.

• Configurar y diseñar políticas.

• Administrar reservaciones y recursos dedicados.

• Monitorear y generar un historial de utilización de recursos para usuarios y grupos.

Principios de Balanceo de Carga

[SUBIR]


 

C3 – Cluster Command & Control

C3 es un conjunto de utilidades basadas en línea de comandos. Éstas son u tilizadas para ejecutar tareas comunes de administración. Estos comandos se diseñaron para proveer un ambiente similar a los comandos comunes que se utilizan bajo la administración de una máquina con UNIX o Linux. Estos comandos son scripts escritos en Phyton.

C3 fue desarrollado por el Laboratorio Nacional Oak Ridge, y su distribución es libre. Esta herramienta se instala automáticamente con la distribución de OSCAR.

cexec
Ejecuta un comando en todos los nodos.

# cexec “ps | grep ps.txt”

cget
Copia archivos de una cierta ubicación en los nodos. Ignora enlaces y directorios. Si existe un nombre de archivo con el mismo nombre lo renombra con un sufijo formado por el nombre del nodo del cluster.

# cget /etc/rc.d/rc.local

ckill
Permite finalizar un proceso en ejecución en los nodos del cluster. Para utilizarlo se utiliza el nombre del proceso, y no su ID de proceso debido que en cada nodo el ID es diferente.

# ckill –u talkd log.txt

cpush
Permite mover archivos de una cierta ubicación en los nodos.

# cget /home/local /home/rc.bk

crm
Permite eliminar archivos y directorios en los nodos. Su funcionamiento es similar al comando rm, con las opciones de interactivo y recursivo.

# crm –iR /home/dafa/ver1/

cshutdown
Permite apagar, reiniciar o suspender un nodo. Las opciones son las mismas del comando shutdown en un sistema Linux. Adiciona el uso de la opción t para especificar el tiempo que tomará para ejecutar la acción.

# cshutdown r t 0

clist , cget , cnum
Son utilizados para hacer consultas de archivos de configuración.

# clist
# cname nombrecluster:0-1
# cnum nodo4.dominio.int

[SUBIR]


 

GANGLIA

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.

[SUBIR]


 

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.

[SUBIR]