Políticas, características e implementación aplicadas a los clúster

Refiere a las políticas asignadas para el uso, implementación de herramientas con su configuración básica y elemental para un correcto funcionamiento de los clúster de la escuela de Ingeniería Civil en Bioinformática de la universidad de Talca.

Políticas por defecto aplicadas al equipo máster de los cluster

• Impedir que se pueda arrancar otro sistema operativo: si alguien tiene acceso físico a la máquina, podría arrancar con otro sistema operativo preconfigurado y modificar el actual, por lo que se debe inhibir desde el BIOS del ordenador el boot por CD-ROM o USB y poner una contraseña de acceso.

• Configuración y red: es recomendable desconectar la red siempre que se deseen hacer ajustes en el sistema. Se debe deshabilitar el dispositivo con /etc/init.d/networking stop (start para activarla de nuevo) o con ifdown eth0 (ifup eth0 para habilitarla) para un dispositivo en concreto.

• Modificar los archivos de /etc/security: de acuerdo a las necesidades de utilización y seguridad del sistema. En access.conf hay información sobre quién puede hacer un login al sistema, por ejemplo:

  # Tabla de control de acceso. líneas con clomuna1=# es un comentario.
  # El orden de la líneas es importante
  # Formato: permission : users : origins
  # Deshabilar todo los logins excepto root sobre tty1
  -:ALL EXCEPT root:tty1
  # User “root” permitido conectarse desde estas direcciones
  + : root : 192.168.200.1 192.168.200.4 192.168.200.9
  + : root : 127.0.0.1
  # O desde la red
  + : root : 192.168.201.
  # Impide el acceso excepto user1,2,3 pero el último solo desde consola.
  -:ALL EXCEPT user1 user2 user3:console

  También se debería, por ejemplo, configurar los grupos para controlar cómo y a dónde pueden acceder y también los límites máximos (limits.conf) para establecer los tiempos máximos de utilización de CPU, E/S, etc. y así evitar ataques por denegación de servicio (DoS).

• Mantener la seguridad de la contraseña de root: utilizar como mínimo 8 caracteres, con uno, por lo menos, en mayúsculas o algún carácter que sea no trivial, como “-”, “.”, “,”, etc.; asimismo, es recomendable activar el envejecimiento para forzar a cambiarlo periódicamente, así como también limitar el número de veces con contraseña incorrecta. También se puede cambiar el parámetro min=x de la entrada en /etc/pam.d/passwd para indicar el número mínimo de caracteres que se utilizarán en la contraseña (x es el número de caracteres). Utilizar algoritmos como SHA512 para la configuración de paswssd.

• No acceder al sistema como root: si bien muchas distribuciones ya incorporan un mecanismo de este estilo (por ejemplo, Ubuntu), se puede crear una cuenta como sysadm y trabajar con ella. Si se accede remotamente, habrá siempre que utilizar shh para conectarse al sysadm y, en caso de ser necesario, realizar un "su -" para trabajar como root o activar el sudoers para trabajar con el comando sudo (consultad la documentación para las opciones del comando y su edición).

• Tiempo máximo de inactividad: inicializar la variable TMOUT, por ejemplo a 360 (valor expresado en segundos), que será el tiempo máximo de inactividad que esperará el shell antes de bloquearse; se puede poner en los archivos de configuración del shell (por ejemplo, /etc/profile, .profile, $HOME/.bashrc, etc.). En caso de utilizar entornos gráficos (KDE, Gnome, etc.), se puede activar el salvapantallas con contraseña, al igual que el modo de suspensión o hibernación.

• Configuración del NFS en forma restrictiva: en el /etc/exports, exportar solo lo necesario, no utilizar comodines (wildcards), permitir solo el acceso de lectura y no permitir el acceso de escritura por root, por ejemplo, con /directorio_exportado host.domain.com (ro, root_squash).

• Control de la combinación Ctrl-Alt-Delete: Para evitar que se apague la máquina desde el teclado, se debe insertar un comentario (#) en la primera columna de la línea siguiente: ca:12345:ctrlaltdel:/sbin/shutdown -t1 -a -r now del archivo /etc/inittab. Los cambios se activan con la orden telinit q.

• Evitar peticiones de servicios no ofrecidos: se debe bloquear el archivo /etc/services, para no admitir servicios no contemplados, por medio de chattr +i /etc/services.

• Conexión del root: hay que modificar el archivo /etc/securetty que contiene las TTY y VC (virtual console) en que se puede conectar el root dejando solo una de cada, por ejemplo, tty1 y vc/1 y, si es necesario, hay que conectarse como sysadm y hacer un su.

• Eliminar usuarios no utilizados: se deben borrar los usuarios o grupos que no sean necesarios, incluidos los que vienen por defecto (por ejemplo, operator, shutdown, ftp, uucp, games, etc.) y dejar solo los necesarios (root, bin, daemon, sync, nobody, sysadm) y los que se hayan creado con la instalación de paquetes o por comandos (lo mismo con /etc/group). Si el sistema es crítico, podría considerarse el bloqueo (chattr +i file) de los archivos /etc/passwd, /etc/shadow, /etc/group, /etc/gsahdow para evitar su modificación (cuidado con esta acción, porque no permitirá cambiar posteriormente las contraseñas).

• Montar las particiones en forma restrictiva: utilizar en /etc/fstab atributos para las particiones tales como nosuid (que impide suplantar el usuario o grupo sobre la partición), nodev (que no interpreta dispositivos de caracteres o bloques sobre esta partición) y noexec (que no permite la ejecución de archivos sobre esta partición). Por ejemplo: /tmp /tmp ext2 defaults,nosuid,noexec 0 0. También es aconsejable montar el /boot en una partición separada y con atributos ro.

• Protecciones varias: se puede cambiar a 700 las protecciones de los archivos de /etc/init.d (servicios del sistema) para que solo el root pueda modificarlos, arrancarlos o pararlos y modificar los archivos /etc/issue y /etc/issue.net para que no den información (sistema operativo, versión, etc.) cuando alguien se conecta por telnet, ssh, etc.

• SUID y SGID: un usuario podrá ejecutar como propietario un comando si tiene el bit SUID o SGID activado, lo cual se refleja como una ‘s’ SUID (-rwsr-xr-x) y SGID (-r-xr-sr-x). Por lo tanto, es necesario quitar el bit (chmod a-s file) a los comandos que no lo necesitan. Estos archivos pueden buscarse con: find / -type f -prem -4000 o -perm -2000 -print. Se debe proceder con cuidado respecto a los archivos en que se quite el SUID-GUID, porque el comando podría quedar inutilizado.

• Archivos sospechosos: hay que buscar periódicamente archivos con nombres no usuales, ocultos o sin un uid/gid válido, como “...” (tres puntos), “.. ” (punto punto espacio), “..ˆG” o equivalentes. Para ello, habrá que utilizar: find / -name=”.*” -print | cat -v o sino find / -name ”..” -print. Para buscar uid/gid no válidos, utilizad find / -nouser (o utilizad también -nogroup (cuidado, porque algunas instalaciones se hacen con un usuario que luego no está definido y que el administrador debe cambiar).

• Conexión sin contraseña: no se debe permitir el archivo .rhosts en ningún usuario, a no ser que sea estrictamente necesario (se recomienda utilizar ssh con clave pública en lugar de métodos basados en .rhosts).

• X Display manager: para indicar los hosts que se podrán conectar a través de XDM y evitar que cualquier host pueda tener una pantalla de login se puede modificar el archivo /etc/X11/xdm/Xaccess.

Acceso y Uso

Todos los Académicos, Funcionarios y estudiantes pudiesen tener acceso a la utilización de los recursos computacionales disponibles por la escuela de Bioinformática.

Solicitud de acceso

Para poder obtener acceso específicamente a los clúster de cálculos computacionales en HPC, los usuarios debiesen pedir autorización a la dirección de carrera justificando las razones del por qué debiese otorgarse el permiso de uso.

Asignación de CPU

Otorgada la autorización el usuario debiese ser encasillarse (rol) en una de las posibilidades para uso en CPU definidas en el cluster. Está se ha estandarizado del siguiente modo:

Asignación de espacio en disco

La definición para todos los usuarios es la asignación de 15GB (soft limit), con la posibilidad de sobrepasarme hasta 20GB por un periodo de 7 días (hard limit).

• Límite débil (soft limit): si la cuenta del usuario o del grupo supera el límite débil, se impondrá un período de gracia en el que el usuario podrá reducir la ocupación.

• Límite duro (hard limit): se deniega cualquier intento de escribir datos después de este límite.

• Período de gracia: tras superar el límite débil, si el usuario no resuelve el problema borrando archivos, la cuenta se bloquea.

El control del espacio en disco será llevado por el paquete "quota".

Para establecer la quota de uso de disco para un usuario se realizará con el programa "edquota", que es un editor de cuotas para usuarios o grupos y que se pueden especificar a través de línea de comandos.

La representación de la imposición de una cuota puede verse en el siguiente ejemplo:

$/sbin/edquote usuarioXXXX

Disk quotas for user usuarioXXXX (uid XXX):
  Filesystem                   blocks       soft       hard     inodes     soft     hard
  /dev/cciss/c0d0p5          32604068       15480000       20480000        401        0        0

En donde:

• 15480000 representa 15GB
• 20480000 representa 20GB

Se puede establecer como referencia este link: http://web.mit.edu/rhel-doc/3/rhel-sag-es-3/ch-disk-quotas.html

Gestor de Colas

Un gestor de colas gestiona trabajos lanzados en una máquina por diferentes usuarios. Para simplificar la configuración al gestor de colas hacia el usuario se ha decidido utilizar solo un nombre o queue para la asociación y denominado talca1 en cada uno de los clúster.

El software de gestión de colas escogido por simplicidad, compatibilidad de software utilizado es PBS.

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.

La versión utilizada de PBS es parte de TORQUE Resource manager es un software que permite gestionar tareas computacionales, que provee control sobre estas tareas y los recursos computacionales de sistemas distribuidos.

Posee los siguientes componentes:

• Servidor: En este caso se llama pbs_server. Permite operaciones básicas como crear, modificar, borrar y ejecutar un trabajo.

• Ejecutor: Es un demonio, llamado en nuestro caso pbs_mom, que pone el comando en ejecución cuando recibe una copia del trabajo de el server.

• Agendador: Otro demonio que tiene las políticas para decidir que trabajo se ejecuta, donde y cuando. Usamos el agendador MAUI el cual se puede comunicar con varios MOMs para comunicar al servidor el estado de los recursos y para conocer del servidor el estado de los trabajos a ejecutar.

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

• 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.
• 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.
• 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.

Politica de configuración estándar para PBS

La configuración de políticas del servidor PBS por defecto para los clúster de Ingeniería Civil en Bioinformática es la siguiente:

set server scheduling = True
set server acl_host_enable = False
set server acl_hosts = clustertalca2.utalca.cl
set server managers = maui@clustertalca2.utalca.cl
set server managers += maui@clustertalca2.local
set server managers += root@clustertalca2.utalca.cl
set server managers += root@clustertalca2.local
set server default_queue = default
set server log_events = 511
set server mail_from = adm
set server query_other_jobs = True
set server scheduler_iteration = 600
set server node_check_rate = 150
set server tcp_timeout = 300
set server job_stat_rate = 45
set server poll_jobs = True
set server mom_job_sync = True
set server allow_node_submit = True
set server next_job_number = 2198
set server server_name = clustertalca2.utalca.cl
set server moab_array_compatible = True
set server nppcu = 2

Esto es seteado a traves del comando qmgr.

Maui

A pesar de que ya tenemos un gestor de colas, se hace necesario tener un planificador de procesos. Es seleccionado es Maui.

MAUI es un planificador externo integrado en el sistema, que periódicamente itera sobre los trabajos pendientes en el gestor de colas.Cada iteración (cuyo intervalo de tiempo varía en función del parámetro RMP POLL), consulta al gestor de colas el estado de los trabajos en el sistema. A partir de esa información, MAUI ordena los trabajos pendientes de ejecución en función de las políticas de prioridad del sistema, y los ejecuta en el orden de mayor a menor prioridad. Presenta la ventaja de ser de código abierto, lo que ha facilitado su rápido crecimiento, y actualmente es uno de los planificador es más extendidos. Permite ser integrado en la gran mayoría de gestores de colas, tales como PBS, LoadLeveler, SGE y BPROC.

Es totalmente configurable a las necesidades del usuario. Como características destacaremos las siguientes:

• Permite definir diferente políticas con diferentes prioridades.
• Posee una interface Metascheduling.
• Permite configurar múltiples políticas backfill.
• Diferentes modos de uso como son el normal, test o monitor.
• Posee un simulador de scheduler que permite analizar workloads para diferentes políticas.

Política de configuración estándar para Maui

La configuración de políticas para aplicar en Maui siguiente:

# maui.cfg.tmpl for Maui v3.2.5
# full parameter docs at http://supercluster.org/mauidocs/a.fparameters.html
# use the 'schedctl -l' command to display current configuration
RMPOLLINTERVAL        00:00:30
SERVERHOST        clustertalca2.utalca.cl
SERVERPORT        42559
SERVERMODE        NORMAL
RMCFG[base]        TYPE=PBS
# Admin: http://supercluster.org/mauidocs/a.esecurity.html
# ADMIN1 users have full scheduler control
ADMIN1                maui root
ADMIN3                ALL
LOGFILE               maui.log
LOGFILEMAXSIZE        10000000
LOGLEVEL              3
# Job Priority: http://supercluster.org/mauidocs/5.1jobprioritization.html
QUEUETIMEWEIGHT       1
# Backfill: http://supercluster.org/mauidocs/8.2backfill.html
BACKFILLPOLICY        FIRSTFIT
RESERVATIONPOLICY     CURRENTHIGHEST
# Node Allocation: http://supercluster.org/mauidocs/5.2nodeallocation.html
NODEALLOCATIONPOLICY  MINRESOURCE

Algunas de la referencias:

https://www.researchgate.net/profile/Brett_Bode/publication/236659354_The_Portable_batch_scheduler_and_the_Maui_Scheduler_on_Linux_Clusters/links/0a85e53b180a2ae39f000000/The-Portable-batch-scheduler-and-the-Maui-Scheduler-on-Linux-Clusters.pdf

http://www.adaptivecomputing.com/products/open-source/maui/

https://www.ibm.com/support/knowledgecenter/en/linuxonibm/liaai.hpcsuse/installingmcs.htm

Monitorización de salud del cluster

Un aspecto importante en el funcionamiento de los clúster es tener una implementación para que el administrador visualice y tenga los datos necesarios para intentar anticipar los problemas. Si se dispone de herramientas adecuadas que puedan prevenir la situación, generar alertas y advertir al responsable de que “algo está pasando” y que este pueda realizar con antelación las acciones correctivas para evitar el fallo, disfunción o situación de fuera de servicio del sistema o recurso.

Ante esto se ha decidido la implementación de Ganglia.

Ganglia

Es una herramienta que permite monitorizar de forma escalable y distribuida el estado de un conjunto de máquinas agrupadas bajo diferentes criterios (red, servicios, etc). El sistema se compone de dos daemons (gmond y gmetad), una página de visualización (ganglia-webfrontend).

En Rock Clusters el servicio viene instalado y configurado por defecto lo cual ofrece una ventaja al momento de implementar.

Algunas características de ganglia:

• La interfaz Web, o mejor conocido como frontend. Esta debe ser instalada en el nodo de administración únicamente.
• 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.

Una buena posibilidad que ofrece ganglia es que también se puede visualizar bajo línea de comandos, esto el práctico en caso no se posea un navegador. Estas herramientas son:

• gstat, la cual provee un medio de comunicación para realizar consultas al demonio gmond, y permite crear reportes del estado del cluster.

• 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.

Para la configurar el servidor Ganglia se debe crear o editar el archivo /etc/ganglia/gmetad.conf, para el caso esto debiesemos tocar la siguiente linea para iniciar el monitoreo.

data_source "clustertalca" localhost:8649

Acá solo se especifica la ip y el puerto de escucha para el servicio de ganglia y solo se configura en el Headnode o equipo máster.

Para los nodos el servicio a supervisar es gmond, que es un demonio que permite monitorizar los cambios de estado en el host, enviar los cambios pertinentes, escuchar el estado de otros nodos.

La configuración en cada nodo debe ser la siguiente:

/* Global Configuration */
globals {
    daemonize = yes
    setuid = yes
    user = nobody
    debug_level = 0
    max_udp_msg_len = 1472
    mute = no
    deaf = yes
    host_dmax = 0 /* secs */
    cleanup_threshold = 300 /* secs */
    gexec = no
    send_metadata_interval = 180 /* secs */
}
/* Cluster Specific attributes */
cluster {
    name = "clustertalca"
    owner = "El Dueño soy YO"
    latlong = "N32.87 W117.22"
    url = "http://icb.utalca.cl"
}
/* Host configuration */
host {
    location="0,1,0"
}
/* UDP Channels for Send and Recv */
udp_recv_channel {
    mcast_join = 224.0.0.3
    port = 8649
}
udp_send_channel {
    mcast_join = 224.0.0.3
    host = 192.168.10.1
    port = 8649
}
/* TCP Accept Channel */
tcp_accept_channel {
    port = 8649
    acl {
        default = "deny"
        access {
            ip = 127.0.0.1
            mask = 32
            action = "allow"
        }
        access {
            ip = 192.168.10.0
            mask = 24
            action = "allow"
        }
    }
}
/* Modules */
modules {
    module {
        name = "core_metrics"
    }
    module {
        name = "cpu_module"
        path = "modcpu.so"
    }
    module {
        name = "disk_module"
        path = "moddisk.so"
    }
    module {
        name = "load_module"
        path = "modload.so"
    }
    module {
        name = "mem_module"
        path = "modmem.so"
    }
    module {
        name = "net_module"
        path = "modnet.so"
    }
    module {
        name = "proc_module"
        path = "modproc.so"
    }
    module {
        name = "sys_module"
        path = "modsys.so"
    }
        module {
                name = "python_module"
                path = "modpython.so"
                params = "/opt/ganglia/lib64/ganglia/python_modules"
        }
}
/* Metrics Collection group */
collection_group {
    collect_every = 60
    time_threshold = 300
    metric {
        name = "location"
        value_threshold = 10.0
    }
    metric {
        name = "load_one"
        value_threshold = 10.0
    }
    metric {
        name = "mem_total"
        value_threshold = 10.0
    }
    metric {
        name = "cpu_intr"
        value_threshold = 10.0
    }
    metric {
        name = "proc_run"
        value_threshold = 10.0
    }
    metric {
        name = "load_five"
        value_threshold = 10.0
    }
    metric {
        name = "disk_free"
        value_threshold = 10.0
    }
    metric {
        name = "mem_cached"
        value_threshold = 10.0
    }
    metric {
        name = "mtu"
        value_threshold = 10.0
    }
    metric {
        name = "cpu_sintr"
        value_threshold = 10.0
    }
    metric {
        name = "pkts_in"
        value_threshold = 10.0
    }
    metric {
        name = "bytes_in"
        value_threshold = 10.0
    }
    metric {
        name = "bytes_out"
        value_threshold = 10.0
    }
    metric {
        name = "swap_total"
        value_threshold = 10.0
    }
    metric {
        name = "mem_free"
        value_threshold = 10.0
    }
    metric {
        name = "load_fifteen"
        value_threshold = 10.0
    }
    metric {
        name = "boottime"
        value_threshold = 10.0
    }
    metric {
        name = "cpu_idle"
        value_threshold = 10.0
    }
    metric {
        name = "cpu_aidle"
        value_threshold = 10.0
    }
    metric {
        name = "cpu_user"
        value_threshold = 10.0
    }
    metric {
        name = "cpu_nice"
        value_threshold = 10.0
    }
    metric {
        name = "sys_clock"
        value_threshold = 10.0
    }
    metric {
        name = "mem_buffers"
        value_threshold = 10.0
    }
    metric {
        name = "cpu_system"
        value_threshold = 10.0
    }
    metric {
        name = "part_max_used"
        value_threshold = 10.0
    }
    metric {
        name = "disk_total"
        value_threshold = 10.0
    }
    metric {
        name = "heartbeat"
        value_threshold = 10.0
    }
    metric {
        name = "mem_shared"
        value_threshold = 10.0
    }
    metric {
        name = "machine_type"
        value_threshold = 10.0
    }
    metric {
        name = "cpu_wio"
        value_threshold = 10.0
    }
    metric {
        name = "proc_total"
        value_threshold = 10.0
    }
    metric {
        name = "cpu_num"
        value_threshold = 10.0
    }
    metric {
        name = "cpu_speed"
        value_threshold = 10.0
    }
    metric {
        name = "pkts_out"
        value_threshold = 10.0
    }
    metric {
        name = "swap_free"
        value_threshold = 10.0
    }
}
include ('/opt/ganglia/etc/conf.d/*.pyconf')

La url para visualizar el monitoreo tiene que ser la siguiente: http://ip-del-cluster/ganglia

Imagenes de Ganglia

Estructuras de particiones del sistema operativo

Nodo Máster

Particiones definidas:

• Raíz (/) 16 GB
• Var (/var) 4 GB
• Memoria de Intercambio (swap) 8GB (1/2 Giga Ram física)
• Home, Share: Resto del disco*

Justificación de la adopción de la medida:

• Sobre el espacio de la partición raíz (/), está motivado en la necesidad de solo albergar el sistema operativo y esto es porque las aplicaciones necesarias y/o requeridas para ejecución deben estar en un directorio compartido y visto por cada uno de los nodos. Esta es la forma de como es el modo de un clúster tipo Beowulf, en donde cada nodo ejecuta la aplicación vía red bajo mismas condiciones.
• La partición /var es creada producto a los logs definidos y además de posibles "share space" que puede utilizar bases de datos de aplicaciones usadas por software de monitoreo de la salud del clúster.
• La memoria de intercambio configurada es de bajo requerimiento de consumo y por regla debe ser así, "el nodo máster no es un equipo de procesamiento".
• Home y Share, son parte de una partición única que contempla la mayor porción del disco que es definida como /state1/partition1.
  • Share, es un directorio global que fue definido como referencia para ser montado y compartido con los demás nodos. Dentro de él podemos definir un numero indeterminados de directorios que serán útiles y visible para cada uno de los esclavos (véase en apartado de directorio compartido).
  • Home, alberga los documentos y archivos destinados y utilizado por los usuarios, teniendo como restricción una quota. Su link simbolico es /share/home y es montado como /home en este equipo.

Ejemplo de /etc/fstab de clustertalca y clustertalca2

LABEL=/                 /                       ext3    defaults        1 1
LABEL=/state/partition  /state/partition1       ext3    defaults,usrquota,grpquota        1 2
LABEL=/var              /var                    ext3    defaults        1 2
tmpfs                   /dev/shm                tmpfs   defaults        0 0
devpts                  /dev/pts                devpts  gid=5,mode=620  0 0
sysfs                   /sys                    sysfs   defaults        0 0
proc                    /proc                   proc    defaults        0 0
LABEL=SW-cciss/c0d0p3   swap                    swap    defaults        0 0

# The ram-backed filesystem for ganglia RRD graph databases.
tmpfs /var/lib/ganglia/rrds tmpfs size=2043372000,gid=nobody,uid=nobody,defaults 1 0

Nodos esclavos

Particiones:

• Raíz (/) 16 GB
• Var (/var) 4 GB
• Memoria de Intercambio (swap) 8GB (1 Giga Ram física)
• Home, Share: NFS Disco Máster

Justificación de la adopción de la medida:

• Sobre el espacio de la partición raíz (/), está motivado en la necesidad de solo albergar el sistema operativo y esto es porque las aplicaciones necesarias y/o requeridas para ejecución deben estar en un directorio compartido proporcionado por el nodo máster.
• Memoria de intercambio esta basada en que es el equipo de procesamiento, y por lo que un cálculo computacional puede requerir más memoria física de la existente.

Directorios compartidos

Los directorio a compartir son los directorios:

• /home que albergará los directorios, archivos y configuraciones personales de cada usuario,
• /share deberá poseer directorios útiles.
  • /share/apps en donde almacenamos todos las aplicaciones necesarias y/o solicitadas en el clúster.

Toda la configuración utilizada está basada en NFS.

El sistema NFS permite a un servidor exportar un sistema de archivo para que pueda ser utilizado de forma interactiva desde un cliente. El servicio se compone básicamente de un servidor (básicamente representado por nfsd* y un cliente (representado por rpc.mountd) que permiten compartir un sistema de archivo (o parte de él) a través de la red.

Nodo Máster

Para compartir un directorio se debe editar el fichero /etc/exports, el que controla cuáles sistemas de archivos son exportados a las máquinas remotas y especifica opciones. Importante es conocer que cada sistema de archivos exportado debe tener su propia línea y cualquier lista de hosts autorizadas colocada después de un sistema de archivos exportado, debe estar separada por un espacio. Las opciones para cada uno de los hosts deben ser colocadas entre paréntesis directamente detrás del identificador del host, sin ningún espacio de separación entre el host y el primer paréntesis.

La configuración propuesta en los clúster en /etc/exports para el nodo máster es:

/export 192.168.10.1(rw,async,no_root_squash) 192.168.10.0/255.255.255.0(rw,async)

Referencia:

http://web.mit.edu/rhel-doc/4/RH-DOCS/rhel-rg-es-4/s1-nfs-server-export.html

Nodo Esclavos

Las comparticiones NFS son montadas en el lado del cliente usando el comando mount. El formato del comando es como sigue:

{{{
mount -t <nfs-type> -o <options> <host>:</remote/export> </local/directory>

}}}

En cada nodo esclavo se utilizará la herramienta de automount, cuya característica es montar y desmontar sistemas de archivos NFS automáticamente, ahorrando recursos.

El servicio autofs es utilizado para controlar el comando automount a través del archivo de configuración primario /etc/auto.master. Mientras que automount puede ser especificado en la línea de comandos, es más conveniente especificar los puntos de montaje, nombres de hosts, directorios exportados y opciones en un conjunto de archivos que teclearlo todo a mano.

El archivo de auto.master definido en el directorio de /etc/ es:

/share /etc/auto.share --timeout=1200
/home  /etc/auto.home  --timeout=1200

Se debe configurar el archivo auto.master en cado de los nodos esclavos y para nuestro caso que apunte un archivo auto.home conteniendo los detalles sobre cómo montar el directorio /home/ vía NFS. Esto permite al usuario acceder a sus datos personales y archivos de configuración en su directorio /home/ conectándose desde cualquier sitio de la red interna.

Ejemplo de /etc/auto.home definido en clustertalca2

user    -nfsvers=3    clustertalca2.local:/export/home/user

Así también se deben configurar los directorios definidos como lo es /etc/auto.share:

apps clustertalca2.local:/export/&

Referencia:

http://web.mit.edu/rhel-doc/4/RH-DOCS/rhel-rg-es-4/s1-nfs-client-config.html

Instalación de Aplicaciones

Todas las implementaciones de aplicaciones deberán estas visadas por la dirección de escuela, por lo que la solicitud debe ser propuesta vía correo electrónico para analizar factibilidad técnica (formas de compilación, compatibilidad de librerías, soporte a sistema operativo, soporte a paralelización y/o distribución, openMPI, disponibilidad de Infiniband, capacidad de cómputo, compatibilidad con PBS, benchmark, etc.).

En la actualidad los clúster poseen aplicaciones destinadas a la simulación molecular (NAMD, Desmond Schrodinger, Lammps). Puede visualizar en los siguiente links:

http://srvbioinf1.utalca.cl/wiki/cluster/clustertalca#Software

http://srvbioinf1.utalca.cl/wiki/cluster/clustertalca2#Software

Las aplicaciones requeridas estarán todas localizadas en el directorio /share/apps y debe garantizar el acceso de todos los nodos (/etc/auto.share).

El árbol directorio a conformar será el siguiente: /share/apps/<apps>/<versionx>, esto a fin de poder identificar la aplicación misma y las versiones de implementadas.

Para el caso de que la aplicación requiera de una actualización para una misma version, se debe crear un nuevo directorio de la siguiente manera /share/apps/<apps>/<versionx-update> y pasar a producción solo cuando el software a sido testeado.

Sandbox

Variables de Entorno

Compilación de herramientas

GCC

referencias:

(1) - https://software.intel.com/en-us/blogs/2012/09/26/gcc-x86-performance-hints

(2) - http://developer.amd.com/wordpress/media/2012/10/CompilerOptQuickRef-62004200.pdf

OpenMPI

Actualización de Sistema

Paridad de paquetes