Computación de Alto Rendimiento con Gentoo Linux

1.  Introducción

Gentoo Linux, es un sabor especial de Linux que puede ser automáticamente optimizado para cualquier aplicación o necesidad. Rendimiento extremo, configurabilidad y una comunidad de usuarios y desarrolladores de la mayor calidad imaginable son característicos de la experiencia Gentoo.

Gracias a una tecnología llamada Portage, Gentoo Linux puede llegar a ser un servidor seguro ideal, una estación de trabajo, un escritorio profesional, un sistema de juegos, una solución que las integre o ... un sistema de computación de alto rendimiento. Debido a su adaptabilidad casi ilimitada, llamamos a Gentoo Linux una metadistribución.

Este documento explica cómo hacer de Gentoo un sistema de computación de alto rendimiento. Explica paso a paso los paquetes a instalar y ayuda a configurarlos.

Gentoo Linux puede obtenerse desde http://www.gentoo.org, y puede obtenerse también la documentación para instalarlo.

2.  Configurando Gentoo Linux para Clustering

Optimizaciones Recomendadas

Durante el proceso de instalación, deben ajustarse los parámetros USE en /etc/portage/make.conf. Recomendamos que se desactiven los valores por defecto (véase /etc/portage/make.profile/make.defaults) negándolos en make.conf. De cualquier forma, pueden conservarse variables como 3dnow, gpm, mmx, nptl, nptlonly, sse, ncurses, pam y tcpd. Consulte la documentación USE para más información.

USE="-oss 3dnow -apm -avi -berkdb -crypt -cups -encode -gdbm -gif gpm -gtk
-imlib -java -jpeg -kde -gnome -libg++ -libwww -mikmod mmx -motif -mpeg ncurses
-nls nptl nptlonly -ogg -opengl pam -pdflib -png -python -qt4 -qtmt
-quicktime -readline -sdl -slang -spell -ssl -svga tcpd -truetype -vorbis -X
-xml2 -xv -zlib"

O sencillamente:

# Copyright 2000-2003 Daniel Robbins, Gentoo Technologies, Inc.
# Contains local system settings for Portage system

# Please review 'man make.conf' for more information.

USE="-* 3dnow gpm mmx ncurses pam sse tcpd"

En el paso 15 ("Instalando el núcleo y los registros del sistema"), por razones de estabilidad, recomendamos las fuentes vanilla (vanilla-sources), el código fuente oficial del núcleo realizado en http://www.kernel.org/, a menos que se requiera soporte específico, como el de xfs.

# emerge -a syslog-ng vanilla-sources

Recomendamos instalar los siguientes paquetes:

# emerge -p nfs-utils portmap tcpdump ssmtp iptables xinetd

Capa de Comunicación (TCP/IP Network)

Un grupo de computadoras (cluster) requiere una capa de comunicación que permita la comunicación entre los nodos esclavos y el nodo maestro. Normalmente, LAN: FastEthernet o GigaEthernet, pueden ser usados, dado que tienen una buena relación precio/rendimiento. Otras posibilidades incluyen el uso de productos como Myrinet, QsNet u otros.

Un cluster se compone de dos tipos de nodo: maestro y esclavo. Normalmente, un cluster dispone de un nodo maestro y varios nodos esclavos.

El nodo maestro es el servidor del cluster. Es el responsable de decirle a los nodos esclavo qué deben hacer. El servidor ejecutará demonios como dhcpd, nfs, pbs-server, y pbs-sched. El nodo maestro permitirá sesiones interactivas de usuarios y aceptará la ejecución de trabajos.

Los nodos esclavo escuchan las instrucciones (quizá vía ssh/rsh) desde el nodo maestro. Deben dedicarse a proporcionar resultados y, por tanto, no deberían ejecutar ningún servicio innecesario.

El resto de este documento asume un cluster cuya configuración es la que se proporciona en el siguiente archivo hosts. Debería mantenerse cada nodo en el archivo /etc/hosts con entradas para cada uno de los nodos que participe en el cluster.

# Adelie Linux Research & Development Center
# /etc/hosts

127.0.0.1       localhost

192.168.1.100   master.adelie master

192.168.1.1     node01.adelie node01
192.168.1.2     node02.adelie node02

Para configurar la LAN dedicada al cluster, se edita el archivo /etc/conf.d/net en el nodo maestro.

# Copyright 1999-2002 Gentoo Technologies, Inc.
# Distributed under the terms of the GNU General Public License, v2 or later

# Global config file for net.* rc-scripts

# This is basically the ifconfig argument without the ifconfig $iface
#

iface_eth0="192.168.1.100 broadcast 192.168.1.255 netmask 255.255.255.0"
# Network Connection to the outside world using dhcp -- configure as required for you network
iface_eth1="dhcp"

Finalmente, se configura un servidor DHCP en el nodo maestro para evitar tener que mantener una configuración de red en cada uno de los nodos esclavo.

# Adelie Linux Research & Development Center
# /etc/dhcp/dhcpd.conf

log-facility local7;
ddns-update-style none;
use-host-decl-names on;

subnet 192.168.1.0 netmask 255.255.255.0 {
        option domain-name "adelie";
        range 192.168.1.10 192.168.1.99;
        option routers 192.168.1.100;

        host node01.adelie {
                # MAC address of network card on node 01
                hardware ethernet 00:07:e9:0f:e2:d4;
                fixed-address 192.168.1.1;
        }
        host node02.adelie {
                # MAC address of network card on node 02
                hardware ethernet 00:07:e9:0f:e2:6b;
                fixed-address 192.168.1.2;
        }
}

NFS/NIS

El sistema de archivos de red (NFS) se desarrolló para permitir a las máquinas montar la partición de un disco en una máquina remota como si estuviese en un disco duro local. Esto permite compartir ficheros a través de una red de forma rápida y eficaz.

Hay otros sistemas que proporcionan una funcionalidad similar a NFS que pueden usarse en entornos cluster. El Andrew File System de IBM, recientemente de código abierto, proporciona un mecanismo que permite compartir archivos con características adicionales de seguridad y rendimiento. El Sistema de archivos Coda se está desarrollando todavía, pero está diseñado para trabajar bien, aún con clientes desconectados. Muchas de las características de los sistemas de archivos Andrew y Coda se incluirán en la siguiente versión de NFS (Versión 4). La ventajas actuales de NFS son que es un sistema maduro, estándar, bien entendido y soportado robustamente en una extensa variedad de plataformas.

# emerge -a nfs-utils portmap

Se ha de configurar e instalar un núcleo con soporte NFS V3 en todos los nodos:

CONFIG_NFS_FS=y
CONFIG_NFSD=y
CONFIG_SUNRPC=y
CONFIG_LOCKD=y
CONFIG_NFSD_V3=y
CONFIG_LOCKD_V4=y

En el nodo maestro, se edita el archivo /etc/hosts.allow para permitir conexiones desde los nodos esclavos. Si la LAN del cluster está en 192.168.1.0/24, el hosts.allow debe ser:

portmap:192.168.1.0/255.255.255.0

Se edita el archivo /etc/exports en el nodo maestro para exportar una estructura de directorios (/home es adecuado para esto).

/home/ *(rw)

Se añade nfs en el nivel de ejecución default del nodo maestro:

# rc-update add nfs default

Para montar el NFS exportado desde el nodo maestro, se tiene que configurar /etc/fstab en los nodos esclavo. Ha de añadirse la siguiente línea:

master:/home/   /home   nfs     rw,exec,noauto,nouser,async     0 0

También se han de configurar los nodos para que monten el sistema de archivos nfs con el siguiente comando:

# rc-update add nfsmount default

RSH/SSH

SSH es un protocolo que proporciona servicios de red seguros, entre ellos el acceso remoto seguro (login), en una red insegura. OpenSSH usa criptografía de una llave pública para asegurar una autorización segura. Generar la llave pública, que es compartida con los sistemas remotos, y la llave privada, que se mantiene en el sistema local, debe hacerse antes de configurar OpenSSH en el cluster.

Para hacer un uso transparente del cluster, pueden usarse las llaves privadas/públicas. Este proceso se hace en dos pasos:

• Generar llaves públicas y privadas
• Copiar la llave pública en los nodos esclavo

Para autenticación basada en usuario, ha de hacerse lo siguiente:

# ssh-keygen -t dsa
Generating public/private dsa key pair.
Enter file in which to save the key (/root/.ssh/id_dsa): /root/.ssh/id_dsa
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /root/.ssh/id_dsa.
Your public key has been saved in /root/.ssh/id_dsa.pub.
The key fingerprint is:
f1:45:15:40:fd:3c:2d:f7:9f:ea:55:df:76:2f:a4:1f root@master


¡AVISO! De tener un archivo "authorized_keys" ha de añadirse al mismo,
no usar el siguiente comando.


# scp /root/.ssh/id_dsa.pub node01:/root/.ssh/authorized_keys
root@master's password:
id_dsa.pub   100%  234     2.0MB/s   00:00

# scp /root/.ssh/id_dsa.pub node02:/root/.ssh/authorized_keys
root@master's password:
id_dsa.pub   100%  234     2.0MB/s   00:00

Para una autenticación basada en el anfitrión se necesita editar también /etc/ssh/shosts.equiv.

node01.adelie
node02.adelie
master.adelie

Y algunas modificaciones al archivo /etc/ssh/sshd_config:

# $OpenBSD: sshd_config,v 1.42 2001/09/20 20:57:51 mouring Exp $
# This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin

# This is the sshd server system-wide configuration file.  See sshd(8)
# for more information.

# HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key

Si la aplicación requiere comunicaciones RSH, se necesita hacer un emerge de net-misc/netkit-rsh y sys-apps/xinetd.

# emerge -a xinetd
# emerge -a netkit-rsh

Entonces se ha de configurar el demonio rsh. Editando el archivo /etc/xinet.d/rsh.

# Adelie Linux Research & Development Center
# /etc/xinetd.d/rsh

service shell
{
        socket_type     = stream
        protocol        = tcp
        wait            = no
        user            = root
        group           = tty
        server          = /usr/sbin/in.rshd
        log_type        = FILE /var/log/rsh
        log_on_success  = PID HOST USERID EXIT DURATION
        log_on_failure  = USERID ATTEMPT
        disable         = no
}

Se edita /etc/hosts.allow para permitir conexiones rsh:

# Adelie Linux Research & Development Center
# /etc/hosts.allow

in.rshd:192.168.1.0/255.255.255.0

O se puede, sencillamente, confiar en la LAN del cluster:

# Adelie Linux Research & Development Center
# /etc/hosts.allow

ALL:192.168.1.0/255.255.255.0

Finalmente, se configura la autenticación del anfitrión en /etc/hosts.equiv.

# Adelie Linux Research & Development Center
# /etc/hosts.equiv

master
node01
node02

Y se añade xinetd al nivel de ejecución default:

# rc-update add xinetd default

NTP

El Protocolo de Tiempo de Red (NTP) se usa para sincronizar el tiempo de una computadora cliente o servidor con otro servidor como fuente de referencia temporal, como un receptor radio o satélite o módem. Proporciona ajustes con una diferencia de un milisegundo en una LAN o de varias decenas de milisegundos en WANs relativas al Tiempo Universal Coordinado (UTC) vía el receptor del Servicio de Posicionamiento Global (GPS), por ejemplo. Las configuraciones típicas de NTP utilizan múltiples servidores redundantes y diversas rutas de red para alcanzar la máxima sincronización posible.

Ha de seleccionarse un servidor NTP geográficamente cercano en Servidores públicos de tiempo NTP, y configurar los archivos /etc/conf.d/ntp y /etc/ntp.conf en el nodo maestro.

# Copyright 1999-2002 Gentoo Technologies, Inc.
# Distributed under the terms of the GNU General Public License v2
# /etc/conf.d/ntpd

# NOTES:
#  - NTPDATE variables below are used if you wish to set your
#    clock when you start the ntp init.d script
#  - make sure that the NTPDATE_CMD will close by itself ...
#    the init.d script will not attempt to kill/stop it
#  - ntpd will be used to maintain synchronization with a time
#    server regardless of what NTPDATE is set to
#  - read each of the comments above each of the variable

# Comment this out if you dont want the init script to warn
# about not having ntpdate setup
NTPDATE_WARN="n"

# Command to run to set the clock initially
# Most people should just uncomment this line ...
# however, if you know what you're doing, and you
# want to use ntpd to set the clock, change this to 'ntpd'
NTPDATE_CMD="ntpdate"

# Options to pass to the above command
# Most people should just uncomment this variable and
# change 'someserver' to a valid hostname which you
# can aquire from the URL's below
NTPDATE_OPTS="-b ntp1.cmc.ec.gc.ca"

##
# A list of available servers is available here:
# http://ntp.isc.org/bin/view/Servers/NTPPoolServers
# Please follow the rules of engagement and use a
# Stratum 2 server (unless you qualify for Stratum 1)
##

# Options to pass to the ntpd process that will *always* be run
# Most people should not uncomment this line ...
# however, if you know what you're doing, feel free to tweak
#NTPD_OPTS=""

Se edita el archivo /etc/ntp.conf en el nodo maestro para configurar una fuente externa de sincronización:

# Adelie Linux Research & Development Center
# /etc/ntp.conf

# Synchronization source #1
server ntp1.cmc.ec.gc.ca
restrict ntp1.cmc.ec.gc.ca
# Synchronization source #2
server ntp2.cmc.ec.gc.ca
restrict ntp2.cmc.ec.gc.ca
stratum 10
driftfile /etc/ntp.drift.server
logfile  /var/log/ntp
broadcast 192.168.1.255
restrict default kod
restrict 127.0.0.1
restrict 192.168.1.0 mask 255.255.255.0

Y en el resto de nodos esclavo, se configura como fuente de sincronización el nodo maestro.

# Copyright 1999-2002 Gentoo Technologies, Inc.
# Distributed under the terms of the GNU General Public License v2
# /etc/conf.d/ntpd

NTPDATE_WARN="n"
NTPDATE_CMD="ntpdate"
NTPDATE_OPTS="-b master"

# Adelie Linux Research & Development Center
# /etc/ntp.conf

# Synchronization source #1
server master
restrict master
stratum 11
driftfile /etc/ntp.drift.server
logfile  /var/log/ntp
restrict default kod
restrict 127.0.0.1

Después se añade ntpd al nivel de ejecución default en todos los nodos:

# rc-update add ntpd default

IPTABLES

Para configurar un cortafuego en el cluster, se necesita iptables.

# emerge -a iptables

Configuración necesaria del núcleo (kernel):

CONFIG_NETFILTER=y
CONFIG_IP_NF_CONNTRACK=y
CONFIG_IP_NF_IPTABLES=y
CONFIG_IP_NF_MATCH_STATE=y
CONFIG_IP_NF_FILTER=y
CONFIG_IP_NF_TARGET_REJECT=y
CONFIG_IP_NF_NAT=y
CONFIG_IP_NF_NAT_NEEDED=y
CONFIG_IP_NF_TARGET_MASQUERADE=y
CONFIG_IP_NF_TARGET_LOG=y

Y las reglas requeridas para este cortafuego:

# Adelie Linux Research & Development Center
# /var/lib/iptables/rules-save

*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -s 192.168.1.0/255.255.255.0 -i eth1 -j ACCEPT
-A INPUT -s 127.0.0.1 -i lo -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -j LOG
-A INPUT -j REJECT --reject-with icmp-port-unreachable
COMMIT
*nat
:PREROUTING ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A POSTROUTING -s 192.168.1.0/255.255.255.0 -j MASQUERADE
COMMIT

Después se añade ipables al nivel de ejecución default en todos los nodos:

# rc-update add iptables default

3.  Herramientas HPC

OpenPBS

El Sistema de Lotes Portables Portable Batch System (PBS) es un sistema flexible de puesta en cola de lotes según la carga de trabajo, originalmente desarrollado para la NASA. Opera en entornos multi-plataforma UNIX, incluyendo clusters heterogéneos de estaciones de trabajo, supercomputadoras, y sistemas paralelos masivos. El desarrollo de PBS está a cargo de Altair Grid Technologies.

# emerge -a openpbs

Antes de empezar a usar OpenPBS, es necesario configurar algunas cosas. Los archivos necesarios para personalizar el sistema son:

• /etc/pbs_environment
• /var/spool/PBS/server_name
• /var/spool/PBS/server_priv/nodes
• /var/spool/PBS/mom_priv/config
• /var/spool/PBS/sched_priv/sched_config

Aquí tenemos una muestra de sched_config:

#
# Create queues and set their attributes.
#
#
# Create and define queue upto4nodes
#
create queue upto4nodes
set queue upto4nodes queue_type = Execution
set queue upto4nodes Priority = 100
set queue upto4nodes resources_max.nodect = 4
set queue upto4nodes resources_min.nodect = 1
set queue upto4nodes enabled = True
set queue upto4nodes started = True
#
# Create and define queue default
#
create queue default
set queue default queue_type = Route
set queue default route_destinations = upto4nodes
set queue default enabled = True
set queue default started = True
#
# Set server attributes.
#
set server scheduling = True
set server acl_host_enable = True
set server default_queue = default
set server log_events = 511
set server mail_from = adm
set server query_other_jobs = True
set server resources_default.neednodes = 1
set server resources_default.nodect = 1
set server resources_default.nodes = 1
set server scheduler_iteration = 60

Para someter una tarea a OpenPBS, se usa el comando qsub con algunos parámetros opcionales. En el siguiente ejemplo, "-l" permite especificar los recursos que se requieren, "-j" permite la redirección de las salidas de error estándar y la salida estándar, y "-m" enviará un correo electrónico al usuario al principio (b), final (e) y al cancelar (a) el trabajo.

(someter y solicitar que myscript sea ejecutado en 2 nodos)
# qsub -l nodes=2 -j oe -m abe myscript

Normalmente, las tareas sometidas a OpenPBS están en forma de macros. A veces, se puede intentar una tarea manualmente. Para solicitar un intérprete de comandos interactivo desde OpenPBS, se usa el parámetro "-I".

# qsub -I

Para comprobar el estado de las tareas, se usa el comando qstat:

# qstat
Job id  Name  User   Time Use S Queue
------  ----  ----   -------- - -----
2.geist STDIN adelie 0        R upto1nodes

MPICH

Pasar Mensajes es un paradigma usado ampliamente en ciertas clases de máquinas en paralelo, especialmente en aquellas con memoria distribuida. MPICH es una implementación portable de MPI disponible libremente. El estándar para las librerías pasar-mensajes.

El ebuild de mpich proporcionado por Adelie Linux permite dos parámetros USE: doc y crypt. doc hará que la documentación sea instalada, mientras que crypt configurará MPICH para usar ssh en lugar de rsh.

# emerge -a mpich

Se debe exportar un directorio de trabajo mpich a todos los nodos esclavo en /etc/exports:

/home *(rw)

La mayoría de sistemas de procesamiento en paralelo masivo (MPPs) proporcionan una forma de iniciar un programa en un número determinado de procesadores; mpirun hace uso del comando adecuado siempre que sea posible. En contraste, los clusters de estaciones de trabajo requieren que cada proceso de un trabajo en paralelo sea iniciado individualmente, aunque programas para iniciar estos procesos existen. Debido a que los clusters con estaciones de trabajo no están organizados como MPP, se requiere información adicional para hacer uso de ellos. Mpich debe ser instalado con una lista de las estaciones de trabajo en el archivo machines.LINUX del directorio /usr/share/mpich/. Este archivo es utilizado por mpirun para elegir los procesadores en los que se ejecuta.

Se edita este archivo para reflejar la configuración del cluster-lan:

# Change this file to contain the machines that you want to use
# to run MPI jobs on.  The format is one host name per line, with either
#    hostname
# or
#    hostname:n
# where n is the number of processors in an SMP.  The hostname should
# be the same as the result from the command "hostname"
master
node01
node02
# node03
# node04
# ...

Se usa el macro tstmachines en /usr/sbin/ para asegurarse de que se pueden usar todas las máquinas de la lista. Esta macro realiza un rsh y un breve listado de directorio; con lo cual se comprueba tanto que se tiene acceso el nodo como que el programa en el directorio puede verse en el nodo remoto. De haber algún problema, será comunicado. Estos problemas deben resolverse antes de proceder.

El único argumento para tstmachines es el nombre de la arquitectura; es el mismo nombre que el del archivo machines. Por ejemplo, lo siguiente comprueba si un programa en el directorio actual puede ser ejecutado por todas las máquinas en la lista LINUX.

# /usr/local/mpich/sbin/tstmachines LINUX

# /usr/local/mpich/sbin/tstmachines -v LINUX

La salida de este comando podría ser:

Trying true on host1.uoffoo.edu ...
Trying true on host2.uoffoo.edu ...
Trying ls on host1.uoffoo.edu ...
Trying ls on host2.uoffoo.edu ...
Trying user program on host1.uoffoo.edu ...
Trying user program on host2.uoffoo.edu ...

Si tstmachines encuentra un problema, sugerirá las posibles razones y las soluciones. Resumidamente, he aquí tres mensajes:

• ¿Se pueden iniciar los procesos en las máquinas remotas? tstmachines intenta ejecutar el comando de shel true en cada máquina que aparece en el archivo de máquinas usando un intérprete de comandos remoto.
• ¿Está disponible el directorio de trabajo para todas las máquinas? Esto intenta hacer un ls de un archivo que crea tstmachines ejecutándolo desde un intérprete de comandos remoto.
• ¿Se pueden ejecutar programas de usuario en los sistemas remotos? Esto comprueba que las librerías compartidas y otros componentes han sido correctamente instalados en todas las máquinas.

Y el test requerido para cada herramienta de desarrollo:

# cd ~
# cp /usr/share/mpich/examples1/hello++.c ~
# make hello++
# mpirun -machinefile /usr/share/mpich/machines.LINUX -np 1 hello++

Para mayor información acerca de MPICH, puede consultarse la documentación de http://www-unix.mcs.anl.gov/mpi/mpich/docs/mpichman-chp4/mpichman-chp4.htm .

LAM

(¡Pronto Disponible!)

OMNI

(¡Pronto Disponible!)

4.  Bibliografía

El documento original se publicó en la página del Centro Adelie Linux R&D, y se ha reproducido aquí con el permiso de los autores y del Centro Cyberlogic de Adelie Linux R&D.

• http://www.gentoo.org, Gentoo Technologies, Inc.
• http://www.adelielinux.com, Adelie Linux Research and Development Centre
• http://nfs.sourceforge.net, Linux NFS Project
• http://www-unix.mcs.anl.gov/mpi/mpich/, Mathematics and Computer Science Division, Argonne National Laboratory
• http://ntp.org
• http://www.eecis.udel.edu/~mills/, David L. Mills, University of Delaware
• http://www.ietf.org/html.charters/secsh-charter.html, Secure Shell Working Group, IETF, Internet Society
• http://www.linuxsecurity.com/, Guardian Digital
• http://www.openpbs.org/, Altair Grid Technologies, LLC.