• Inicio

Tabla de Contenidos

  1. Políticas, características e implementación aplicadas a los clúster
    1. Políticas por defecto aplicadas al equipo máster de los cluster
    2. Acceso y Uso
      1. Solicitud de acceso
      2. Asignación de CPU
      3. Asignación de espacio en disco
    3. Gestor de Colas
      1. PBS
        1. Politica de configuración estándar para PBS
      2. Maui
        1. Política de configuración estándar para Maui
    4. Monitorización de salud del cluster
      1. Ganglia
        1. Imagenes de Ganglia
    5. Estructuras de particiones del sistema operativo
      1. Nodo Máster
      2. Nodos esclavos
    6. Directorios compartidos
      1. Nodo Máster
      2. Nodo Esclavos
    7. Instalación de Aplicaciones
      1. Sandbox de aplicaciones
    8. Variables de Entorno
    9. Compilación de herramientas
      1. GCC
      2. OpenMPI
    10. Actualización de Sistema
      1. Paridad de paquetes entre los nodos

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

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:

Rol

Cantidad de CPU disponible

Máximo de trabajos en paralelos

Prioridad de ejecución

Estudiante de Pregrado

64

1

0

Estudiante de Postgrado

80

1

43200

Postgrado Memorista

96

1

43200

Docentes

128

2

86400

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

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:

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:

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

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:

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:

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:

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 política de 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

attachment:ganglia-clustertalca2-1 attachment:ganglia-clustertalca2-2 attachment:ganglia-clustertalca2-3 attachment:ganglia-clustertalca2-4

Estructuras de particiones del sistema operativo

Nodo Máster

Particiones definidas:

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

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:

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

Directorios compartidos

Los directorio a compartir son los directorios:

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 política de configuración propuesta en los clúster para /etc/exports en 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 establecido para cada nodo esclavo y localizado 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.).

Las aplicaciones deben ser compiladas a fin de adecuarse de mejor modo a la infraestructura del clúster, y de no ser así buscar el binario específico para el equipo y sus componentes (clúster beowulf, openMPI, Infiniband, etc).

No deben instalarse aplicaciones de repositorio, puesto a que son genéricas y la posible perdida de performance es latente.

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 de aplicaciones

Nuestra política no es restringir a los usuarios a utilizar o experimentar herramientas dentro del cluster, por lo que tienen la posibilidad de poder compilar e instalar dentro del espacio asociado a su cuenta la aplicación deseada. La limitación corre por el uso del espacio en disco, vea aquí.

Variables de Entorno

Las variables de entorno forman un conjunto de valores dinámicos que normalmente afectan al comportamiento de los procesos en una computadora.

Algunas de las variables más utilizadas:

La mejor forma que se ha decidido para agregar o editar las variables de entorno que afecten a todos los usuarios es agregar un fichero (nueva-variable-entorno.sh) a /etc/profile.d/ en donde se cargarán de forma automática ante un nuevo inicio de sesión.

Un ejemplo puede ser para nuestra implementación de gcc 6.3.0: 

$cat /etc/profile.d/gcc.sh

export PATH=/share/apps/gcc/6.3.0/bin:$PATH
export LD_LIBRARY_PATH=/share/apps/gcc/6.3.0/lib64:$LD_LIBRARY_PATH
export INCLUDE=/share/apps/gcc/6.3.0/include/c++/6.3.0/:$INCLUDE

La prioridad de acceso es primer directorio que lee es primero donde busca el paquete o librería.

El usuario puede tener la habilidad de poder modificar las variables de entorno, solo de enunciarlas vía terminal (export) o instanciarlas desde un archivo bash.

Compilación de herramientas

GCC

El GNU Compiler Collection (colección de compiladores GNU) es un conjunto de compiladores creados por el proyecto GNU. GCC es software libre y lo distribuye la Free Software Foundation (FSF) bajo la licencia general pública GPL.

La url del proyecto es: https://gcc.gnu.org/

La última implementación de GCC realizada ha sido en nuestros clúster ha sido la versión 6.3 (gcc-6.3.0.tar.bz2). La forma de compilar GCC en nuestras máquinas es la siguiente:

Estableciendo dependencias:

Librerías de Desarrollo 

$ tar jxvf gcc-6.3.0.tar.bz2
$ mkdir /share/apps/gcc/6.3/
$ cd gcc-6.3.0
$ ./configure --enable-shared --enable-threads=posix --enable-__cxa_atexit \
--enable-clocale=gnu --enable-languages=fortran,objc \
--prefix=/share/apps/gcc/6.3/

La explicación del comando:

Se puede y debe compilar con un modo de optimización al procesador dependiendo del clúster 

make -j8

-j8 : Si tenemos un procesador de ocho núcleos (octa-core) y el kernel está optimizado para el mismo, con este parámetro aumentaremos el número de procesos de compilación simultáneos a ocho obteniendo un tiempo de compilación del programa de forma considerable.

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

OpenMPI es una implementación de la interfaz de paso de mensajes MPI. OpenMPI se caracteriza por su alta eficiencia y prestaciones para la ejecución en entornos distribuidos (clústers de ordenadores).

La implementación de rocks contempla una instancia de OpenMPI por defecto que incluye al nodo máster como esclavos.

Las versiones instaladas son:

Pero por requerimientos de nuevos softwares se hace necesario tener disponibles otras versiones.

Las versiones de OpenMPI se pueden implementar sin problema, siempre y cuando sea en modo "Sandbox" y localizada en /share/apps/openmpi/<version> esto porque para la vinculación con el mismo debe ser invocado de modo explicito.

Para instalar se debe, descargar la versión de OpenMPI deseada desde la url https://www.open-mpi.org/software/.

Posterior ejecutar los siguientes pasos: 

tar -xvf openmpi-<version>

cd openmpi-<version>

./configure --prefix=/share/apps/openmpi/<version>

make -j8 all

su -c 'make install'

Para ejecutar OpenMPI el usuario debe editar sus variables de entorno de PATH y LD_LIBRARY_PATH, esto sería 

export PATH=/share/apps/openmpi/<version>/bin:$PATH

export LD_LIBRARY_PATH=/share/apps/openmpi/<version>/lib:$LD_LIBRARY_PATH

Las versiones de OpenMPI instaladas en /share/apps/openmpi/<version> en los clúster son:

En los nodos esclavos no se toca nada, por el contrario todo cambio en variables de entorno se deben realizar en el archivo bash envíado al gestor de colas para la adopción de estás nuevas rutas en los nodos para la sesión.

Actualización de Sistema

Los clúster solo actualizarán su sistema desde repositorios oficiales de CentOS (Rock Cluster está basado en CentOS) y/o Red Hat, permaneciendo por defecto deshabilitados, habilitandose solo cuando sea invocado el comando de actualización.

Ejemplo de repositorios clustertalca y clustertalca2 

$ cat /etc/yum.repos.d/CentOS-Base.repo
# CentOS-Base.repo
#
# The mirror system uses the connecting IP address of the client and the
# update status of each mirror to pick mirrors that are updated to and
# geographically close to the client.  You should use this for CentOS updates
# unless you are manually picking other mirrors.
#
# If the mirrorlist= does not work for you, as a fall back you can try the
# remarked out baseurl= line instead.
#
#
[base]
enabled = 0
name=CentOS-$releasever - Base
mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=os
#baseurl=http://mirror.centos.org/centos/$releasever/os/$basearch/
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-6
#released updates
[updates]
enabled = 0
name=CentOS-$releasever - Updates
mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=updates
#baseurl=http://mirror.centos.org/centos/$releasever/updates/$basearch/
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-6
#additional packages that may be useful
[extras]
enabled = 0
name=CentOS-$releasever - Extras
mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=extras
#baseurl=http://mirror.centos.org/centos/$releasever/extras/$basearch/
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-6
#additional packages that extend functionality of existing packages
[centosplus]
enabled = 0
name=CentOS-$releasever - Plus
mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=centosplus
#baseurl=http://mirror.centos.org/centos/$releasever/centosplus/$basearch/
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-6
#contrib - packages by Centos Users
[contrib]
enabled = 0
name=CentOS-$releasever - Contrib
mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=contrib
#baseurl=http://mirror.centos.org/centos/$releasever/contrib/$basearch/
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-6

$ cat /etc/yum.repos.d/elrepo.repo
### Name: ELRepo.org Community Enterprise Linux Repository for el6
### URL: http://elrepo.org/
[elrepo]
enabled = 0
name=ELRepo.org Community Enterprise Linux Repository - el6
baseurl=http://elrepo.org/linux/elrepo/el6/$basearch/
mirrorlist=http://elrepo.org/mirrors-elrepo.el6
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-elrepo.org
protect=0
[elrepo-testing]
enabled = 0
name=ELRepo.org Community Enterprise Linux Testing Repository - el6
baseurl=http://elrepo.org/linux/testing/el6/$basearch/
mirrorlist=http://elrepo.org/mirrors-elrepo-testing.el6
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-elrepo.org
protect=0
[elrepo-kernel]
enabled = 0
name=ELRepo.org Community Enterprise Linux Kernel Repository - el6
baseurl=http://elrepo.org/linux/kernel/el6/$basearch/
mirrorlist=http://elrepo.org/mirrors-elrepo-kernel.el6
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-elrepo.org
protect=0
[elrepo-extras]
enabled = 0
name=ELRepo.org Community Enterprise Linux Repository - el6
baseurl=http://elrepo.org/linux/extras/el6/$basearch/
mirrorlist=http://elrepo.org/mirrors-elrepo-extras.el6
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-elrepo.org
protect=0

Solo se actualizará mediante red el nodo máster, realizando los siguientes comandos: 

yum clean all

yum check-update --enablerepo=base,updates

yum upgrade --enablerepo=base,update

Paridad de paquetes entre los nodos

Una de las particularidades de Rocks es poder crear imagenes de instalación a partir de una actualización, por lo que se debe realizar lo siguiente: 

cp /var/cache/yum/updates/packages/*  /export/rocks/install/contrib/<version>/<arch>/RPMS/
cd /export/rocks/install
rocks create distro
rocks run host compute "/boot/kickstart/cluster-kickstart"

Lo anterior realizará:

Referencia:

http://www.rocksclusters.org/roll-documentation/base/5.5/update.html

cluster/politicas (última edición 2017-05-17 19:14:18 efectuada por FabioDuran)