Sep 27, 2009

File system benchmark en Linux

En el presente artículo vamos a analizar distintas herramientas que se tienen en Linux para hacer pruebas de rendimiento sobre un sistema de almacenamiento.

Esta clase de aplicaciones pueden llegar a ser muy interesantes cuando se quiere medir el rendimiento o alcance de un determinado sistema de archivos (ext4, ext3, NTFS, GFS, etc.) o una clase concreta de acceso a datos (NFS, GNBD, iSCSI, etc.), obteniendo información como la velocidad de escritura, lectura, latencias, etc.

Por ejemplo, se puede tener la necesidad de montar un espacio de almacenamiento en red al que accedan concurrentemente múltiples servidores, y en una primera etapa de evaluación se planteen dos posibles escenarios: acceso mediante NFS a un sistema de ficheros ext3 o GFS2.

cp

Comando utilizado para copiar archivos desde un origen a un destino. La siguiente orden lo que hará será medir el tiempo empleado en escribir un determinado fichero de XXXX · YYYY bytes en disco (directorio /tmp).
# dd if=/dev/zero of=file bs=XXXX count=YYYY && time cp file /mnt/tmp

Una forma habitual de uso del comando cp puede ser por ejemplo transferir el directorio /etc (122 MB, 1999 archivos) o /lib (207 MB, 3746 archivos). De esta forma se consigue el copiado de múltiples ficheros de diferentes tamaños, los cuales se encuentran ubicados en distintos subdirectorios.

dd

Permite el copiado de datos bit a bit independientemente del sistema de ficheros origen y destino. Como información de salida ofrece la velocidad de lectura/escritura con la que se ha realizado la operación, así como el tiempo empleado.

El formato que utilizaremos para el comando dd será el siguiente:

  • Lectura de XXXX · YYYY bytes desde el disco /dev/sda al dispositivo /dev/null.
    # dd if=/dev/sda of=/dev/null bs=XXXX count=YYYY
  • Escritura de XXXX · YYYY bytes desde el dispositivo origen /dev/zero al fichero /tmp/output.
    # dd if=/dev/zero of=/tmp/output bs=XXXX count=YYYY
El dispositivo /dev/null descarta toda la información volcada en él de forma instantánea. De esta forma, al aplicar el primer comando el tiempo de cómputo se invertirá exclusivamente en la lectura de datos.

Decir que /dev/zero es un dispositivo especial que cuando se lee de él proporciona caracteres NULL, es decir, su tiempo de lectura es prácticamente nulo. De esta forma, al aplicar el segundo comando el tiempo de cómputo se invertirá exclusivamente en la escritura de datos.

Una forma habitual de uso de dd es por ejemplo leer y escribir un fichero superior a la memoria RAM total (por ejemplo 5 GB en caso de disponer de 4 GB de memoria RAM). Esa transferencia se realizará seis veces, tanto en lectura (R) como en escritura (W). Se irá variando los valores de XXXX e YYYY de tal forma que su multiplicación dé 5 GB. De esta forma mediremos la tasa de transferencia y el tiempo empleado.
bs (bytes)  count  velocidad-R (MB/sg)  tiempo-R (sg)   velocidad-W (MB/sg)  tiempo-W (sg)
65536 78125
131072 39062
262144 19531
524288 9765
1048576 4882
2097152 2441

Con bs igual a 65536 se emplearán registros de 64 KB para hacer las transferencias.

IOzone

IOzone es una herramienta de benchmark destinada a comprobar el rendimiento de un sistema de archivos. La aplicación genera y mide una gran cantidad de operaciones sobre ficheros. La forma de ejecutar IOzone es la siguiente:

# iozone [options] > logfile

IOzone dispone de distintas opciones para poder pasar por la línea de órdenes; a continuación vamos a exponer las más interesantes de cara a medir el rendimiento de un sistema de archivos:
  • -a: modo automático completo.
  • -b excel_file: genera un archivo en formato Excel con los resultados obtenidos (formato binario).
  • -c: incluye en los resultados los tiempos empleados para cerrar los ficheros.
  • -f filename: especifica el archivo temporal que se empleará para los tests.
  • -g size: tamaño máximo del archivo (Ej. -g 2G, igual o superior al tamaño de la memoria RAM) para el modo auto (-a).
  • -i test: especifica el tipo de test a utilizar (0: escritura/re-escritura, 1: lectura/re-lectura, 2: lectura/escritura aleatoria, ...).
  • -l num: número mínimo de procesos.
  • -r size: tamaño fijo del registro utilizado para hacer las transferencias.
  • -s size: tamaño fijo del archivo utilizado para hacer las transferencias.
  • -u num: número máximo de procesos.
  • -z: esta opción utilizada junto con el parámetro -a, fuerza a IOzone a emplear archivos pequeños durante las pruebas.
  • -F filename1 filename2 ...: especifica los archivos temporales que se emplearán para los tests.
  • -R: genera un informe Excel.
  • -U mountpoint: punto de montaje a desmontar y montar durante el transcurso de los tests.

Las distintas definiciones de los tests son las siguientes:

  • Escritura: mide el rendimiento de escritura secuencial en un nuevo archivo.
  • Re-escritura: mide el rendimiento de escritura secuencial sobre un archivo que ya existe.
  • Lectura: mide el rendimiento de lectura secuencial sobre un archivo existente.
  • Re-lectura: mide el rendimiento de lectura secuencial sobre un archivo que ha sido recientemente leído.
  • Escritura aleatoria: mide el rendimiento de escritura aleatoria en un nuevo archivo.
  • Lectura aleatoria: mide el rendimiento de lectura aleatoria sobre un archivo ya existente.
Una forma habitual de uso de IOzone puede ser la siguiente:
# iozone -Razc -i 0 -i 1 -g 4G -f /mnt/tmp/file -b fichero.xls

La orden anterior ejecuta un test de lectura/escritura secuencial, variando los tamaños de los ficheros empleados desde 64 KB a 4 GB, utilizando buffers de transferencia comprendidos entre 4 KB y 16 MB. Como resultado final se generará un fichero Excel a partir del cual podremos crear las correspondientes gráficas.

Esto último es lo que se conoce como barrido de un determinado espectro de almacenamiento, y tiene como principal objetivo el de poder generar una gráfica de superficie que determine el comportamiento del sistema ante variaciones de los registros y ficheros empleados.

Para este caso le hemos indicado a iozone que utilice el fichero file, el cual deberá encontrarse sobre el sistema de archivos que queremos comprobar, siendo en este caso /mnt/tmp.

En esta clase de pruebas es conveniente utilizar un tamaño de fichero máximo (parámetro -g) superior a la memoria RAM disponible. De esta forma se podrá obtener el comportamiento de la máquina cuando utiliza la memoria cache del procesador (tamaño del archivo inferior a la cache del procesador), cuando emplea la memoria RAM (tamaño del archivo comprendido entre la cache del procesador y la cantidad total de memoria RAM) o cuando hace uso directamente de las operaciones de entrada/salida a disco (tamaño del archivo superior a la memoria RAM).

Otra forma habitual de empleo de IOzone está destinada a medir el impacto de diferente número de procesos sobre dicho sistema de archivos. Por ejemplo, la orden siguiente hará que varios procesos (desde 1 a 50) vayan realizando operaciones de lectura/escritura secuencial de un fichero de 4 MB, utilizando para ello registros de 64 KB.
[... tmp]# iozone -Rc -r 64 -s 4MB -l 1 -u 50 -i 0 -i 1 -b /root/fichero.xls

A diferencia del caso anterior, esta vez nos hemos situado sobre el directorio a testear (sistema de archivos), ya que de esta forma cada uno de los procesos que lance IOzone irá creando su fichero temporal correspondiente. Otra alternativa hubiera sido no ubicarse en dicho directorio y a través de la opción -F indicar los diferentes ficheros a utilizar, uno por cada proceso implicado, es decir, en nuestro caso hasta un total de 50 ficheros deberían haberse definido con la opción -F.

El ejemplo anterior se suele utilizar para obtener el comportamiento de múltiples procesos del sistema manejando archivos pequeños. Para completar las pruebas de IOzone es conveniente repetir este test pero utilizando archivos más grandes (y aumentando a su vez el tamaño de los registros).
[... tmp]# iozone -Rc -r 1024 -s 512MB -l 1 -u 12 -i 0 -i 1 -b /root/fichero.xls

Bonnie++

Bonnie++ es un programa utilizado para comprobar el rendimiento de discos duros y sistemas de archivos. Bonnie++ permite la creación de distintos tests de lectura, escritura y borrado de archivos de diversos tamaños, etc. Bonnie++ tiene muchos parámetros que pueden ser empleados, pero la forma en la que lo utilizaremos para medir el rendimiento de un sistema de ficheros será la siguiente:
# bonnie++ -d /tmp [-n number:max:min:num-directories] [-s size] -u 0

A través de la opción -d se especifica el directorio a utilizar durante el transcurso de las pruebas. El parámetro number es el número de archivos que serán creados multiplicado por 1024, el cual vendrá precedido de la opción -n. Si se especifican los valores max y min, los archivos serán creados con un tamaño aleatorio comprendido entre esas dos cotas (bytes). Y si de declara el parámetro directories, los archivos serán distribuidos uniformemente a través de una estructura de directorios con una profundidad máxima marcada por el parámetro directories.

Con la opción -s se indica a través del valor size, el tamaño del archivo que será utilizado para las pruebas de lectura y escritura. Este tamaño debe ser como mínimo el doble de la memoria RAM. Y con la opción -u 0 se indica a Bonnie++ que ejecute las pruebas como usuario root.

Los resultados mostrados por Bonnie++ ofrecen velocidades de escritura secuencial (Sequential Output) y lectura secuencial (Sequential Input). También ofrecen valores sobre la creación secuencial (Sequential Create) y aleatoria (Random Create) de ficheros, así como de borrado secuencial (Sequential Delete) y aleatorio (Random Delete) de ficheros.

Bonnie++ trae consigo una herramienta que nos permite generar un fichero en formato HTML (bon_csv2html) a partir de los resultados obtenidos (última línea de datos). Para ello deberemos ejecutar la siguiente secuencia de órdenes:
# echo "última_línea_de_datos"  bon_csv2html > fichero.html

Una forma habitual de uso de Bonnie++ puede ser la siguiente:
# bonnie++ -n 128 -s 7544 -x 1 -u 0 -d /mnt/tmp/

La orden anterior ejecuta una sola vez (-x 1), un test de lectura y escritura de un archivo de 7,5 GB, así como la tarea de creación y borrado de 131072 ficheros (128x1024) de 0 bytes.

Por último, decir que es importante limpiar los datos cacheados en la memoria RAM al terminar cada una de las pruebas.

Sep 20, 2009

Almacenamiento compartido en red: GFS2 + NFS (II)

En esta segunda parte del artículo Almacenamiento compartido en red: GFS2 + NFS, vamos a ver cómo securizar la infraestructura con SELinux, TCP wrappers e iptables.

SELinux

Si se tiene activado SELinux con la opción de enforcing (bloqueo), éste va a impedir el funcionamiento normal del servidor centos01 bloqueando ciertas acciones que en base a las políticas de seguridad que trae por defecto, no son correctas o no están permitidas.

La solución pasa por crear un módulo de política local para SELinux que permita dichos accesos. Este módulo se puede generar a partir de los eventos registrados en el archivo audit.log.

Primero vamos a activar SELinux en modo permisivo en el nodo centos01. Dicha opción habrá que establecerla en su fichero de configuración. También habrá que reiniciar la máquina para que todos los ficheros se etiqueten correctamente.
[root@centos01 ~]# vim /etc/selinux/config
...
SELINUX=permissive
SELINUXTYPE=targeted

SELinux en modo permisivo registrará las alertas de seguridad en el fichero audit.log pero no bloqueará las acciones.

A continuación vamos a vaciar el fichero audit.log del nodo centos01; seguidamente detendremos e iniciaremos el cluster y a partir de los eventos registrados en el archivo audit.log, generaremos un módulo de política local (cluster.te) y lo instalaremos.
[root@centos01 ~]# >/var/log/audit/audit.log

[root@centos01 ~]# service clvmd stop
[root@centos01 ~]# service rgmanager stop
[root@centos01 ~]# service cman stop
[root@centos01 ~]# service gfs2 stop

[root@centos01 ~]# service gfs2 start
[root@centos01 ~]# service cman start
[root@centos01 ~]# service rgmanager start
[root@centos01 ~]# service clvmd start

[root@centos01 ~]# audit2allow -m local -l -i /var/log/audit/audit.log > cluster.te

[root@centos01 ~]# cat cluster.te
module local 1.0;

require {
type ccs_t;
type tmpfs_t;
type initrc_t;
class sem { unix_read write unix_write associate read destroy };
class shm { write unix_read unix_write associate read destroy };
class file { read write };
}

#============= ccs_t ==============
allow ccs_t initrc_t:sem { unix_read write unix_write associate read destroy };
allow ccs_t initrc_t:shm { write unix_read unix_write associate read destroy };
allow ccs_t tmpfs_t:file { read write };

Antes de poder instalar el módulo, habrá que compilarlo (cluster.mod) y obtener el paquete de seguridad correspondiente (cluster.pp), el cual ya podremos instalar en el nodo centos01.
[root@centos01 ~]# checkmodule -M -m -o cluster.mod cluster.te

[root@centos01 ~]# semodule_package -o cluster.pp -m cluster.mod

[root@centos01 ~]# semodule -i cluster.pp

Y ya por último, para activar SELinux en modo enforcing (bloqueante) ejecutaremos el comando setenforce 1. Y para hacer que este cambio sea persistente tras sucesivos reinicios de la máquina, activaremos esta opción en el fichero de configuración de SELinux.
[root@centos01 ~]# setenforce 1

[root@centos01 ~]# cat /etc/selinux/config
...
SELINUX=enforcing
SELINUXTYPE=targeted

TCP wrappers

Para securizar el servidor centos01 con TCP wrappers, vamos a habilitar los servicios portmap (demonio de asignación de puertos dinámicos) y mountd (demonio encargado de la gestión de volúmenes NFS) para el rango de direcciones IP de los nodos centos02 y centos03.
[root@centos01 ~]# cat /etc/hosts.deny
ALL: ALL

[root@centos01 ~]# cat /etc/hosts.allow
sshd: ALL
portmap: 192.168.1.
mountd: 192.168.1.

Para que el servicio NFS pueda ser posteriormente protegido por iptables, tendremos que añadir los siguientes puertos al fichero /etc/sysconfig/nfs.
[root@centos01 ~]# cat /etc/sysconfig/nfs
...
MOUNTD_PORT="4002"
STATD_PORT="4003"
LOCKD_TCPPORT="4004"
LOCKD_UDPPORT="4004"
RQUOTAD_PORT="4005"

Iptables

Los puertos que hay que abrir en iptables son los utilizados por los servicios cman (Cluster Manager, 5404 y 5405 UDP), NFS (Network File System, 111 TCP y UDP, 2049 TCP y UDP, 4002:4005 TCP y UDP), modclusterd (16851 TCP) y dlm (Distributed Lock Manager, 21064 TCP).

A continuación se muestra el contenido del fichero de configuración de iptables para el nodo centos01.
[root@centos01 ~]# cat /etc/sysconfig/iptables
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:RH-Firewall-1-INPUT - [0:0]
-A INPUT -j RH-Firewall-1-INPUT
-A FORWARD -j RH-Firewall-1-INPUT
-A RH-Firewall-1-INPUT -i lo -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
-A RH-Firewall-1-INPUT -p tcp --dport ssh -j ACCEPT
-A RH-Firewall-1-INPUT -p icmp -j ACCEPT
-A RH-Firewall-1-INPUT -s 192.168.1.0/24 -p tcp --dport 111 -j ACCEPT
-A RH-Firewall-1-INPUT -s 192.168.1.0/24 -p udp --dport 111 -j ACCEPT
-A RH-Firewall-1-INPUT -s 192.168.1.0/24 -p tcp --dport 2049 -j ACCEPT
-A RH-Firewall-1-INPUT -s 192.168.1.0/24 -p udp --dport 2049 -j ACCEPT
-A RH-Firewall-1-INPUT -s 192.168.1.0/24 -p tcp --dport 4002:4005 -j ACCEPT
-A RH-Firewall-1-INPUT -s 192.168.1.0/24 -p udp --dport 4002:4005 -j ACCEPT
-A RH-Firewall-1-INPUT -s 192.168.1.0/24 -p udp -m multiport --dport 5404,5405 -j ACCEPT
-A RH-Firewall-1-INPUT -s 192.168.1.0/24 -p tcp --dport 16851 -j ACCEPT
-A RH-Firewall-1-INPUT -s 192.168.1.0/24 -p tcp --dport 21064 -j ACCEPT
-A RH-Firewall-1-INPUT -j LOG
-A RH-Firewall-1-INPUT -j REJECT
COMMIT

[root@centos01 ~]# service iptables restart

[root@centos01 ~]# chkconfig iptables on

Sep 14, 2009

Almacenamiento compartido en red: GFS2 + NFS (I)

En el presente artículo vamos a desarrollar una arquitectura de almacenamiento compartido a la que accederán de forma concurrente un par de máquinas. Las pruebas van a ser realizadas bajo un sistema operativo de tipo CentOS 5.3.

El área de datos sobre el que se configurará el acceso compartido será un volumen lógico (LogVol00) cuyo sistema de archivos será GFS2 (Global File System 2).

GFS es un sistema de ficheros nativo creado por Red Hat y distribuido bajo licencia GNU, que puede ser utilizado de forma local (como por ejemplo ext3) o en cluster, de manera que varios nodos puedan estar trabajando simultáneamente sobre él sin peligro a que se corrompan los datos. El máximo tamaño de almacenamiento que soporta GFS2 es de 8 EB.

En la figura siguiente puede observarse que el espacio de almacenamiento compartido se instalará sobre la máquina centos01, el cual será exportado a los nodos centos02 y centos03 a través de NFS4 (Network File System v4).


NFS es un protocolo perteneciente al nivel de aplicación utilizado para sistemas de ficheros distribuidos, que permite que varios nodos puedan acceder de forma simultánea a distintos archivos remotos. Todas las operaciones de escritura son síncronas, es decir, la tarea se da por finalizada cuando realmente se ha terminado de escribir el último byte.

Cada una de las máquinas deberá tener registrado los nombres de todos los nodos en el fichero /etc/hosts.
[... ~]# cat /etc/hosts
...
192.168.1.11 centos01 centos01.local
192.168.1.12 centos02 centos02.local
192.168.1.13 centos03 centos03.local

SELinux deberá estar desactivado en el nodo centos01, al igual que iptables y TCP wrappers. Al final del artículo veremos la forma de configurarlos correctamente para que no interfieran en el sistema de almacenamiento.
[root@centos01 ~]# setenforce 0

[root@centos01 ~]# service iptables stop

[root@centos01 ~]# cat /etc/hosts.deny
...
#ALL: ALL

En los nodos centos02 y centos03 estos tres mecanismos de seguridad podrán estar activados:
[... ~]# getenforce
Enforcing

[... ~]# cat /etc/hosts.deny
...
ALL: ALL

[... ~]# iptables -nL
Chain INPUT (policy ACCEPT)
target prot opt source destination
RH-Firewall-1-INPUT all -- 0.0.0.0/0 0.0.0.0/0

Chain FORWARD (policy ACCEPT)
target prot opt source destination
RH-Firewall-1-INPUT all -- 0.0.0.0/0 0.0.0.0/0

Chain OUTPUT (policy ACCEPT)
target prot opt source destination

Chain RH-Firewall-1-INPUT (2 references)
target prot opt source destination
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:22
ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0
LOG all -- 0.0.0.0/0 0.0.0.0/0 LOG flags 0 level 4
REJECT all -- 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable

Lo primero que vamos a hacer es instalar el software necesario en el nodo centos01.
[root@centos01 ~]# yum install lvm2-cluster rgmanager gfs2-utils

Seguidamente vamos a crear el volumen lógico que se empleará como espacio compartido en centos01, utilizando para ello una partición de 64 GB que ya tendremos creada previamente y etiquetada como Linux LVM.
[root@centos01 ~]# fdisk -l
...
Disposit. Inicio Comienzo Fin Bloques Id Sistema
/dev/sdb1 1 8354 67103473+ 8e Linux LVM

Primero habrá que crear un volumen físico sobre esa partición, después el grupo de volúmenes (VolGroup01) y por último el volumen lógico (LogVol00).
[root@centos01 ~]# pvcreate /dev/sdb1

[root@centos01 ~]# vgcreate VolGroup01 /dev/sdb1

[root@centos01 ~]# lvcreate -l 100%FREE -n LogVol00 VolGroup01

Una vez que ya se tiene creado el volumen lógico, crearemos dentro de él un sistema de archivos GFS2. El parámetro lock_dlm indica el protocolo de bloqueo a emplear, siendo lock_dlm (DLM - Distributed Lock Manager) para el caso de acceso concurrente y lock_nolock para el caso de acceso de un único nodo. Con la opción de -t se especifica el nombre del cluster y el nombre que le queremos dar al sistema de archivos, y con la opción -j se indica el número de nodos que accederán concurrentemente al sistema de archivos.
[root@centos01 ~]# mkfs.gfs2 -p lock_dlm -t mycluster:gfs2_data -j 3 /dev/VolGroup01/LogVol00

Si en un momento dado deseamos conocer el número de nodos asociados al sistema GFS2, podremos ejecutar el siguiente comando:
[root@centos01 ~]# gfs2_tool journals /dev/VolGroup01/LogVol00
journal2 - 128MB
journal1 - 128MB
journal0 - 128MB
3 journal(s) found.

A continuación se va a crear en centos01, un archivo denominado cluster.conf el cual refleje la arquitectura que se quiere establecer (directorio /mnt/gfs2_nfs cuyo sistema de archivos es GFS2 y exportado a través del protocolo NFS4 a los nodos centos02 y centos03).

[root@centos01 ~]# cat /etc/cluster/cluster.conf
<?xml version="1.0"?>
<cluster alias="mycluster" config_version="1" name="mycluster">
<fence_daemon clean_start="0" post_fail_delay="0" post_join_delay="3"/>
<clusternodes>
<clusternode name="centos01.local" nodeid="1" votes="1">
<fence/>
</clusternode>
</clusternodes>
<cman/>
<fencedevices/>
<rm>
<failoverdomains/>
<resources>
<nfsexport name="resource_nfs_export"/>
<clusterfs device="/dev/VolGroup01/LogVol00" force_unmount="0" fsid="31803" fstype="gfs2" mountpoint="/mnt/gfs2_nfs" name="resource_gfs2" self_fence="0"/>
<nfsclient allow_recover="1" name="resource_nfs_client_centos02" options="rw,sync,root_squash,fsid=0" target="centos02.local"/>
<nfsclient allow_recover="1" name="resource_nfs_client_centos03" options="rw,sync,root_squash,fsid=0" target="centos03.local"/>
</resources>
<service autostart="1" exclusive="0" max_restarts="0" name="service_centos01" recovery="restart" restart_expire_time="0">
<clusterfs fstype="gfs" ref="resource_gfs2">
<nfsexport ref="resource_nfs_export">
<nfsclient name=" " ref="resource_nfs_client_centos02"/>
<nfsclient name=" " ref="resource_nfs_client_centos03"/>
</nfsexport>
</clusterfs>
</service>
</rm>
</cluster>

En una primera sección (clusternodes) se define el nombre del nodo (clusternode name) que ofrecerá el servicio NFS.

La otra sección principal del fichero de configuración es la de los recursos. Se han definido cuatro recursos: un dispositivo (GFS2) que será montado en el directorio /mnt/gfs2_nfs, un directorio a exportar (/mnt/gfs2_nfs) y dos clientes (centos02 y centos03) a los que se les permitirá importar dicho directorio.

A su vez se ha creado un servicio denominado service_centos01 el cual iniciará y detendrá ciertos recursos (nfsexport, clusterfs, clusterfs, ...).

Así de esta forma el servicio service_centos01 hará que cuando se inicie automáticamente (autostart="1"), se monte el recurso resource_gfs2, se exporte el directorio /mnt/gfs2_nfs asociado al recurso resource_nfs_export e implícitamente a los nodos centos02 y centos03 a través de los recursos resource_nfs_client_centos02 y resource_nfs_client_centos03.

Las opciones de exportación empleadas para NFS han sido rw (permitir la lectura y escritura), sync (escrituras síncronas) , root_squash (root accederá como usuario anónimo - nobody) y fsid=0 (habilitar NFSv4).

Se ha dicho que el dispositivo a exportar deberá ser montado previamente en el directorio /mnt/gfs2_nfs. Por lo tanto, también tendremos que crear dicho directorio. A su vez, en los nodos centos02 y centos03 crearemos el mismo directorio en el cual montaremos el volumen NFS importado.
[root@centos01 ~]# mkdir /mnt/gfs2_nfs

[root@centos02 ~]# mkdir /mnt/gfs2_nfs

[root@centos03 ~]# mkdir /mnt/gfs2_nfs

Para que los nodos centos02 y centos03 puedan importar automáticamente dicho directorio durante el arranque, tendremos que añadir al fichero /etc/fstab de ambos nodos el siguiente contenido:
[... ~]# cat /etc/fstab
...
centos01.local:/ /mnt/gfs2_nfs/ nfs4 defaults 0 0

Por último, sólo tendremos que reiniciar los servicios gfs2, cman, rgmanager y clvmd en el nodo centos01, y mediante el comando chkconfig haremos que dichos demonios se inicien automáticamente cada vez que arranque el nodo. También tendremos que otorgar permisos de escritura para el resto de usuarios, al directorio exportado.
[root@centos01 ~]# service gfs2 restart

[root@centos01 ~]# service cman restart

[root@centos01 ~]# service rgmanager restart

[root@centos01 ~]# service clvmd restart


[root@centos01 ~]# chkconfig gfs2 on

[root@centos01 ~]# chkconfig cman on

[root@centos01 ~]# chkconfig rgmanager on

[root@centos01 ~]# chkconfig clvmd on


[root@centos01 ~]# chmod -R o+w /mnt/gfs2_nfs/

Si ejecutamos el comando clustat, podremos ver la configuración actual del cluster que acabamos de levantar. Por un lado se tiene la lista de miembros del cluster (Member Name) y por el otro, la lista de servicios definidos (Service Name), así como su propietario (Owner) y estado (State).
[root@centos01 ~]# clustat
Cluster Status for mycluster @ Wed Jul 22 17:04:00 2009
Member Status: Quorate

Member Name ID Status
------ ---- ---- ------
centos01.local 1 Online, Local, rgmanager

Service Name Owner (Last) State
------- ---- ----- ------ -----
service:service_centos01 centos01.local started

Para que los nodos centos02 y centos03 monten en este momento el sistema de ficheros exportado por centos01, únicamente tendremos que ejecutar el siguiente comando en ambos nodos:
[... ~]# mount -a

Sep 7, 2009

Protección y desinfección del virus Conficker

En los siguientes dos apartados se presentan las medidas necesarios a tomar con el objetivo de prevenir el contagio de un sistema operativo perteneciente a la familia Microsoft Windows por parte del virus Conficker, así como las acciones a realizar para el caso de una infección ya detectada.

McAfee dispone de una serie de herramientas destinadas a combatir el virus Conficker. Entre ellas hay que destacar a Stinger, que permite detectar y limpiar todas las variantes de este tipo de malware, así como el Conficker Detection Tool, utilizado para realizar un escáner de red con el objetivo de descubrir máquinas infectadas por el virus Conficker.

Medias preventivas

A continuación se describen una serie de medidas preventivas que serían necesarias tomar para proteger a los servidores de un hipotético ataque por parte del virus Conficker:
  • Aplicar como mínimo el parche asociado al boletín de seguridad (MS08-67) publicado por Microsoft con respecto a la vulnerabilidad explotada por el virus Conficker.
  • Deshabilitar la función de auto-ejecución de los sistemas operativos, siguiendo las indicaciones expuestas por Microsoft en su artículo 967715.
  • Utilizar contraseñas seguras en los equipos.
  • Limitar los permisos sobre los recursos compartidos.
  • Deshabilitar las cuentas administrativas por defecto.
  • Renombrar las cuentas de los administradores.
Desinfección de los equipos afectados

A continuación se exponen las medidas necesarias que habría que tomar para desinfectar y proteger a un equipo afectado por parte del virus Conficker:
  • Actualizar el fichero de firmas del antivirus a la última versión.
  • Ejecutar un análisis completo de todo el equipo.
  • Reiniciar el sistema.
  • Volver a realizar un análisis completo sobre el equipo.