Apuntes RH436

1.
- GESTIÓN DE DATOS, ALMACENAMIENTO Y TECNOLOGÍA

CLUSTER
Los datos de usuario suelen tener requerimientos y retos más complejos que los datos de sistema. Los
datos de sistema son fácilmente recreados desde los CDs de instalación y una cantidad relativamente
de datos desde un back-up.
Los datos de sistema se suelen volver a usar para arquitecturas similares, mientras que los datos de
usuario son muy específicos y dependientes de cada uno de ellos.
¿Podrían los datos ser compartidos mediante varias máquinas? ¿Son los datos específicos de cada
arquitectura?
1.1 ¿QUÉ ES UN CLUSTER?
Los clusters de alto rendimiento (o clusters computacionales) son a veces referidos como computación
en GRID, dado el uso de CPU que hacen varios sistemas para llevar a cabo cálculos concurrentes.
Trabajando en paralelo, muchas aplicaciones (como las de renderización de animaciones o una amplia
variedad de modelos de simulación de problemas) pueden mejorar sensiblemente su rendimiento.
Los cluster de aplicaciones de alta disponibilidad a veces son llamados clusters de fail-over
(recuperación a fallos). Su propósito es proveer de continua disponibilidad a un determinado
servicio eliminando los puntos únicos de fallo. A través de la redundancia (tanto hardware como
software) un sistema altamente disponible puede proveeer virtualmente disponibilidad continua a
uno o varios servicios. Los clusters de fail-over normalmente se asocian con servicios que conllevan
lecturas y escrituras de datos. Realizar el fail-over de un proceso de lectura/escritura de un sistema de
ficheros montado es algo complejo y un sistema de fail-over debe tener provisiones para mantener
la integridad de los datos mientras que un sistema toma el control de un servicio desde el sistema
fallado.
Los clusters de balanceo de carga, envían las peticiones de servicio de red a múltiples sistemas
para repartir las peticiones de carga sobre múltiples sistemas. Los balanceadores de carga proveen
escalabilidad a un coste efectivo, puesto que más sistemas se pueden añadir según cambien los
requerimientos. En vez de invertir en un sistema muy caro, es posible invertir en varios sistemas
pequeños x86, de esta manera, si un servidor en cluster falla, el software de cluster detectará este fallo
y enviará las peticiones a otros servidores operacionales dentro del cluster. Un cliente externo no se
dará cuenta de este fallo en absoluto, puesto que el cluster parece un único sistema.
Lo que distingue un cluster de alta disponibilidad (HA) de un cluster de balanceo de carga es la

relación de “fail-over” de sistemas a almacenes de datos.
1.2. TOPOLOGÍA DE CLUSTER
Red Hat Enterprise Clustering and Storage Management

Red Hat Cluster Suite incluye y provee la infraestructura para clusters HA y de failover, así como GFS.
Los clusters HA proveen la capacidad para que un servicio se mantenga altamente disponible en el
grupo de nodos de cluster haciendo fail-over (reubicandolo) a un nodo que aún sea funcional dentro
del “dominio de fail-over”.
GFS complementa al Cluster Suite proveeiendo gestión de volúmenes conscientes de cluster y acceso
a sistemas de archivos concurrentes para mas de una E/S de kernel (almacenamiento compartido).
Los clusters de fail-over HA son independientes de los clusteres GFS, si bien pueden coexistir y trabajar
juntos.
1.3. MODELO DE ALMACENAMIENTO DE RHEL
VFS (Virtual File System) es una capa de interfaz (dentro del kernel) que maneja las llamadas al kernel
relacionadas con sistemas de ficheros. VFS también gestiona la caché de disco.
El driver de sitema de archivos recible la llamada del sistema que ha recibido VFS, VFS pues, traduce
las llamadas genéricas a las propias de cada sistema de archivos.
El driver del dispositivo de bloques envía las peticiones de bajo nivel al driver que implementa el
dispositivo de bloques que contiene el sistema de ficheros.

1.4. GESTIÓN DE VOLÚMENES
Los volumenes son una forma de agregación de bloques que describen los límites físicos de los datos.
Estos límites presentan restricciones físicas de hardware y su abstracción o virtualización.
LUN: Logical Unit Number, identificador único dentro de la cabina.

UUID: Universally Unique IDentifier, único en el mundo, es un identificador de 128 bits y se usa para
identificar un sistema de forma única en un entorno distribuído. Se suele generar a partir del S/N.
[root@station9 ~]# blkid

/dev/mapper/vol0-home: UUID="5f24ae1b-0428-4f17-b481-36f4411a2e36" TYPE="ext3"
/dev/mapper/vol0-root: UUID="2ae88f03-d2dd-4c62-980b-3167ca85fa6d" TYPE="ext3"
/dev/sda3: LABEL="SWAP-sda3" TYPE="swap"
/dev/sda1: LABEL="/boot1" UUID="3267fd2d-c175-47f6-8bfc-150a5688b15c" TYPE="ext3"
SEC_TYPE="ext2"
/dev/vol0/root: UUID="2ae88f03-d2dd-4c62-980b-3167ca85fa6d" TYPE="ext3"
1.5. ACCESO A VOLUMENES DE DATOS
DAS: Direct Attached Storage, es un dispositivo al que tengo acceso exclusivo (típicamente mis discos
internos)
Shared Storage: dispositivos que están igualmente compartidos/accedidos.
SAN
NAS
1.5.1 SAN, STORAGE AREA NETWORK
Una red de área de almacenamiento, en inglés SAN (storage area network), es una red concebida
para conectar servidores, matrices (arrays) de discos y librerías de soporte. Principalmente, está
basada en tecnología fibre channel y más recientemente en iSCSI. Su función es la de conectar de
manera rápida, segura y fiable los distintos elementos que la conforman.
Componentes típicos de una red de fibra son:

Cable de fibra óptica: sin interferencias eléctricas y mayores distancias
Controladora de fibra, HBA (host bus adaptor): es como una tarjeta de red, pero con mayor
inteligencia, pues implementa todos los protocolos del stack de fibra a nivel hardware. El SO no
la trata como una tarjeta de red, sino como un controlador de dispositivo.
Tecnología de switch de fibra: base de la red de fibra, define la topología de cómo los puertos
de red son ordenados y el camino que seguirán los datos en caso de fallo. A la red de fibra se le
suele llamar fabric.
Topología punto a punto: sin switch, de cada máquina a cada cabina.
Topología de loop arbitrado: todos los dispositivos se ordenan en una conexión en
bucle.
Topología con switch fabric: todos los dispositivos están conectados a uno o más
switches de fibra, que administran la conexión y canales de comunicación.
Internet SCSI, iSCSI, es un protocolo que posibilita que los clientes (iniciadores) envién comandos

remotos de almacenamiento a dispositivos (target). La ventaja es que usa cualquier red IP existente,
haciendolo así más fácil y en teoría, más barato que la fibra.
Network Power Switch (NPS) provee mecanismos para automatizar de manera remota la gestión
de electricidad. Es como una regleta con un puerto ethernet al que nos podemos conectar y cortar el
suministro eléctrico a uno de los puertos.
Una red SAN se distingue de otros modos de almacenamiento en red por el modo de acceso a bajo
nivel. El tipo de tráfico en una SAN es muy similar al de los discos duros como ATA, SATA y SCSI. En
otros métodos de almacenamiento, (como SMB o NFS), el servidor solicita un determinado fichero,
p.ej."/home/usuario/rocks". En una SAN el servidor solicita "el bloque 6000 del disco 4".
1.5.2 NAS, NETWORK ATTACHED STORAGE
Es el nombre dado a una tecnología de almacenamiento dedicada a compartir la capacidad de

almacenamiento de un computador (Servidor) con ordenadores personales o servidores clientes a
través de una red (normalmente TCP/IP), haciendo uso de un Sistema Operativo optimizado para dar
acceso con los protocolos CIFS, NFS, FTP o TFTP. Generalmente, los sistemas NAS son dispositivos
de almacenamiento específicos a los que se accede desde los equipos a través de protocolos de red
(normalmente TCP/IP).
A diferencia de SAN, NAS ofrece la garantía de la coherencia de datos.
1.6. REDES DE NODOS DE CLUSTER.
Los heartbeat de los clusters no pueden ser separados del trafico de comunicación del cluster, por
tanto el tráfico y los servicios de los clusters deberían estar separados usando distintas subredes o
distintos interfaces de red. Así podemos definir la red pública y la red privada.
Un monitorizador de links de red puede disparar un failover de servicio cuando se detecte el fallo del
link.
Los canales de “bonding” (agregación) de ethernet pueden proveer paths adicionales de trafico de
failover.
El equipamiento de red ha de soportar multicast, pues es como se comunican los nodos de los
clusters (el direccionamiento se genera automáticamente cuando se crea el cluster, aunque puede ser
cambiado manualmente.)

Para poder probar si se puede acceder a un grupo multicast, (haciendo ping) usamos netstat -g
para ver las direcciones multicast asignadas.
[root@station9 ~]# netstat -g

IPv6/IPv4 Group Memberships
Interface RefCnt Group
--------------- ------ ---------------------
lo 1 ALL-SYSTEMS.MCAST.NET
cluster 1 224.0.0.251
cluster 1 ALL-SYSTEMS.MCAST.NET
storage1 1 224.0.0.251
storage1 1 ALL-SYSTEMS.MCAST.NET
storage2 1 224.0.0.251
storage2 1 ALL-SYSTEMS.MCAST.NET
virbr0 1 224.0.0.251
virbr0 1 ALL-SYSTEMS.MCAST.NET
eth0 1 224.0.0.251
eth0 1 ALL-SYSTEMS.MCAST.NET
1.7. BONDING ETHERNET
Sirve para hacer agragación de enlaces, consiguiendo una red altamente disponible y/o más rápida.
Evita los puntos únicos de fallos.
Pasos para configurarlo:

1.- Cargar y configurar el modulo del bond en /etc/modprobe.conf
vi /etc/modprobe.conf
alias bond0 bonding
options bond0 mode=1 miimon=100 use_carrier=0
2.- Configurar los interfaces de bonding.

cd /etc/sysconfig/network-scripts
vi ifcfg-bond0
-----------
DEVICE=bond0
IPADDR=192.0.2.1
NETMASK=255.255.255.0
GATEWAY=192.0.2.254
ONBOOT=yes
BOOTPROTO=static
BONDING_OPTS=”mode=1 miimon=100” #Ésta es la forma correcta de pasar #parámetros no
en el fichero /etc/modprobe.conf
3.- Indicar los interfaces físicos que serán miembros del bond:
cd /etc/sysconfig/network-scripts
vi ifcfg-eth0
-------------
DEVICE=eth0
MASTER=bond0
SLAVE=yes

ONBOOT=yes
BOOTPROTO=static
vi ifcfg-eth1
--------------
DEVICE=eth1
MASTER=bond0
SLAVE=yes
ONBOOT=yes
BOOTPROTO=static
A la hora de configurar interfaces bonding para multiplicar ancho de banda (sobre todo con round
robin), hay que tener en cuenta la configuración del switch (trunking); el modo 1 (active backup) no
tiene este problema.
Bonding no hace fail-back (obviamente, sí hace fail-over) si se pone el parámetro “primary=interfaz” sí

hará fail-back.
1.8. MULTIPATHING
Es una metodología de acceso a disco. En principio surgió como una implementación de acceso SCSI
por múltiples vías. Conforma una capa de conmutación para distintos caminos al mismo dispositivo de
almacenamiento.
1.9. SEGURIDAD DEL CLUSTER
Todas las comunicaciones entre nodos van encriptadas por defecto. OpenAIS usa el nombre del
cluster como clave de encriptación.
Por otro lado hay que asegurarse que los puertos del FW están abiertos para permitir la comunicación
entre nodos, los siguientes puertos han de estar abiertos.
PORT NUMBER SERVICE PROTOCOL

5404, 5405 cman udp
11111 ricci tcp
14567 gnbd tcp
16851 modclusterd (part of Conga) tcp
21064 dlm tcp
50006, 50008, ccsd tcp
50009
50007 ccsd udp
La recomendación es empezar con un FW simple que permita las comunicaciones entre las máquinas,
sin importar los puertos.
2.- udev

Es un software que sirve para gestionar los nombres de dispositivos de manera persistente.
udev es el gestor de dispositivos que usa el kernel de Linux en su versión 2.6. Su función es controlar
los ficheros de dispositivo en /dev. Es el sucesor de devfs y de hotplug, lo que significa que maneja el
directorio /dev y todas las acciones del espacio de usuario al agregar o quitar dispositivos, incluyendo
la carga de firmware.
udev sigue el Linux Standard Base (LSB) para las convenciones de nomenclaturas, pero permite
personalización por parte del usuario:
# cd /dev
# ln -s sda midisco
Los números major y minor son irrelevantes para udev.
En un sistema Linux tradicional (sin udev ni devfs), en el directorio /dev hay nodos de dispositivo
creados para cada dispositivo conocido, esté o no en el sistema. Se dice que es un conjunto de ficheros
estático, ya que los nodos no cambian.
Además, la forma de acceder a un periférico concreto no es siempre la misma, ya que depende
de qué otros aparatos hay conectados: si se conectan los discos A y B, se llamarán disco1 y disco2
respectivamente. Pero si está sólo un disco (el B, por ejemplo), se llamará disco1, porque sólo hay uno.
El B ha cambiado de nombre.
Este modelo de gestión de dispositivos tiene algunos problemas:
● el directorio /dev es enorme y difícil de manejar, ya que incluye todos los dispositivos posibles
● los números mayor y menor que se asocian a cada dispositivo se estaban acabando
● los usuarios necesitan que cada dispositivo sea accesible de la misma manera; no aceptarán
que por conectar un disco USB al sistema tengan que reconfigurar la cámara de vídeo.
● los programas necesitan poder detectar cuándo se ha conectado o desconectado un
dispositivo, y cuál es la entrada que se le ha asociado en /dev
udev soluciona estos problemas, sobre todo el de poder acceder a un dispositivo con un nombre
siempre fijo. Ésta fue la razón por la que se hizo udev, ya que antes estaba devfs, que solucionaba
alguno de estos problemas, pero no todos.
2.1. HAL, HARDWARE ABSTRACTION LAYER
La capa HAL provee a las aplicaciones de una forma sencilla para reconocer hardware en el sistema.
Antes las aplicaciones de escritorio descubrían el hardware “hablando” directamente con el kernel,
ya que éste mantiene una lista de dispositivos conectados al sistema. Este proceso no siempre
funcionaba correctamente. Con HAL toda la información sobre ciertas clases de hardware es
fácilmente accesible en un formato bien definido.
Cuando un dispositivo nuevo se conecta al sistema se envía una señal asíncrona al bus de mensajes
del sistema detallando qué tipo de dispositivo se ha añadido. Cualquier aplicación de escritorio se
puede conectar al bus de mensajes para descubrir hardware. Internamente, el demonio HAL mantiene
una lista de objetos directorio que contiene pares de clave/valor bien definidas que describen lo
que el objeto representa. Cada dispositivo es identificado por un Identificador Único de Dispositivo
(Universally Unique IDentifier, UUID). Los pares de clave/valor, llamados propiedades del dispositivo,
están definidos en la especificación del HAL.

Una vez que el demonio HAL ha recogido toda la información sobre un dispositivo, incluyendo la
fusión de información de los archivos de información sobre dispositivos, ya está listo para anunciar la
presencia del nuevo objeto dispositivo.
2.2. CADENA DE EVENTOS PARA UN NUEVO DISPOSITIVO ENCHUFADO
1. El kernel descubre el dispositivo y exporta su estado al sysfs.

2. udev es notificado del evento a través de un socket de netlink.
3. udev crea el nodo de dispositivo y/o ejecuta los programas pertinentes (ficheros de reglas).
4. udev notifica al demonio hald el evento a través de un socket.
5. HAL prueba el dispositivo para obtener información.
6. HAL puebla las estructuras de objetos del dispositivo con la información obtenida en la prueba y
otras fuentes.
7. HAL hace un broadcast del evento sobre el D-Bus.
8. Una aplicación del espacio de usuario monitoriza dichos eventos para procesar la información.
En este curso nos centraremos en los 3 primeros eventos unicamente.
Cuando un dispositivo se añade o quita del sistema, el kernel envía un mensaje a udevd e informa de
la información des dispositivo a través de /sys. udev entonces, busca información del sistema en /sys
y determina basandose en reglas personalizables y en la información encontrada en /sys, cuál es el
nodo de dispositivo o enlace simbólico a crear, cuáles son sus atributos y/o qué acciones llevar a cabo.
sysfs se usa para que udev pueda preguntar los atributos sobre todos los dispositivos en el sistema
(ubicación, nombre, número de serie, números major / minor, vendor o product ID, etc). udev tiene
un sistema de reglas de usuario para determinar los nombre de dispositivos y las acciones a realizar
cuando éstos de cargan o descargan.
udev accede la la información de los dispositivos de sysfs usando la librería de llamadas libsysfs.
libsysfs tiene un interfaz consistente estándar para todas las aplicaciones que necesitan preguntar a
sysfs para información de dispositivos. El comando udevmonitor es útil para monitorizar los eventos
de kernel y de udev, tales como el deschenfufado de un dispositivo. La opción --env da información de
las variables de entorno relacionadas.
Cada uno de los ficheros que existan en el directorio /sys/block/DISPOSITIVO pueden ser usados como
reglas de udev. También podemos verlo con el comando udevinfo:
[root@station9 rules.d]# udevinfo -q name -p /sys/block/sdb

sdb
[root@station9 rules.d]# udevinfo -q all -p /sys/block/sdb
P: /block/sdb
N: sdb
S: disk/by-id/usb-S31B1010_USB_DISK_AA330463000360007269
S: disk/by-path/pci-0000:00:1d.7-usb-0:8:1.0-scsi-0:0:0:0
E: ID_VENDOR=S31B1010
E: ID_MODEL=USB_DISK
E: ID_REVISION=1100
E: ID_SERIAL=S31B1010_USB_DISK_AA330463000360007269

E: ID_TYPE=disk
E: ID_BUS=usb
E: ID_PATH=pci-0000:00:1d.7-usb-0:8:1.0-scsi-0:0:0:0
# Relativo a /dev, usamos -n
[root@station9 rules.d]# udevinfo -q all -n /dev/sdb
P: /block/sdb
N: sdb
E: ID_REVISION=1100
E: ID_TYPE=disk
E: ID_BUS=usb
El comando udevinfo -a dispositivo nos da toda la información relativa a dicho dispositivo en la

forma en la que podemos usarla dentro de un fichero de reglas (usa la misma sintaxis).
Por defecto, udev lee ficheros con extensión “.rules” que estén ubicados en el directorio
/etc/udev/rules.d. Normalmente los ficheros de reglas se nomenclan empezando por un entero de
2 dígitos seguidos de un nombre descriptivo. udev ejecuta las reglas en orden alfabético, por tanto el
número sirve para establecer el orden de ejecución.
El formato de una regla de udev se divide de manera lógica en 2 partes separadas en la misma línea:
uno o más pares clave-valor usados para emparejar los atributos del dispositivo y/o las características
a algún valor; y una o más asignaciones de pares clave-valor que asignan un valor al dispositivo, tal
como el nombre.
En el siguiente ejemplo, al dispositivo USB con el SN 20043512321411d34721 se le asignará un enlace

simbólico adicional llamado /dev/usb_backup.
Ej: BUS=="usb", SYSFS{serial}=="20043512321411d34721", SYMLINK+="usb_backup"
Para obtener el UUID de un dispositivo SCSI usamos el comando scsi_id (el -g es para sacar el
dispositivo de la black list y obterner su información; con la opción -x generamos variables que se
pueden importar):
[root@station9 rules.d]# scsi_id -g -s /block/sda

SATA ST380815AS 6RX25Y65
[root@station9 rules.d]# scsi_id -g -u -s /block/sda
SATA_ST380815AS_6RX25Y65_
[root@station9 rules.d]# scsi_id -g -u -x -s /block/sda
ID_VENDOR=ATA
ID_MODEL=ST380815AS
ID_REVISION=3.CH
ID_SERIAL=SATA_ST380815AS_6RX25Y65
ID_TYPE=disk
udev crea bajo /dev/disk unos cuantos nombres predefinidos (y persistentes) bajo varios criterios

distintos:
[root@station9 rules.d]# cd /dev/disk/

[root@station9 disk]# ls
by-id by-label by-path by-uuid
[root@station9 disk]# ls by-path/pci-0000\:00\:1*
by-path/pci-0000:00:1d.7-usb-0:8:1.0-scsi-0:0:0:0 by-path/pci-0000:00:1f.2-scsi-
0:0:0:0-part2
by-path/pci-0000:00:1d.7-usb-0:8:1.0-scsi-0:0:0:0-part1 by-path/pci-0000:00:1f.2-
scsi-0:0:0:0-part3
by-path/pci-0000:00:1f.1-ide-0:0 by-path/pci-0000:00:1f.2-scsi-
0:0:0:0-part4
by-path/pci-0000:00:1f.2-scsi-0:0:0:0 by-path/pci-0000:00:1f.2-scsi-
0:0:0:0-part5
by-path/pci-0000:00:1f.2-scsi-0:0:0:0-part1
[root@station9 disk]# ls by-id/*
by-id/scsi-SATA_ST380815AS_6RX25Y65 by-id/scsi-SATA_ST380815AS_6RX25Y65-part4
by-id/scsi-SATA_ST380815AS_6RX25Y65-part1 by-id/scsi-SATA_ST380815AS_6RX25Y65-part5
by-id/scsi-SATA_ST380815AS_6RX25Y65-part2 by-id/usb-
S31B1010_USB_DISK_AA330463000360007269
by-id/scsi-SATA_ST380815AS_6RX25Y65-part3 by-id/usb-
S31B1010_USB_DISK_AA330463000360007269-part1
Ejercicios
1.- Crear un nuevo dispositivo con las siguientes reglas:
Owner: student
Group: student
Mode: 0600
Name: /dev/sda6
[root@station9 disk]# vi /etc/udev/rules.d/75-classlab_local.rules

KERNEL=="sda6", OWNER="student", GROUP="student", MODE="0600"
[root@station9 disk]# partprobe /dev/sda
[root@station9 disk]# ll /dev/sda6
brw------- 1 student student 8, 6 Nov 29 15:38 /dev/sda6
2.- Crear una regla para un pendrive USB con los siguientes atributos:
Owner: student
Group: student
Mode: 0600
Name: /dev/sda6
Obtengo información de mi dispositivo

[root@station9 disk]# udevinfo -q all -n /dev/sdb
P: /block/sdb
N: sdb
E: ID_REVISION=1100

E: ID_TYPE=disk
E: ID_BUS=usb
[root@station9 ~]# udevinfo -a -p /block/sdb | grep serial

SYSFS{serial}=="AA330463000360007269"
SYSFS{serial}=="0000:00:1d.7"
[root@station9 disk]# vi /etc/udev/rules.d/75-classlab_local.rules
KERNEL=="sd*", DRIVER=="usb", SYSFS{serial}=="AA330463000360007269",
SYMLINK+="usbflash%n", OWNER="student", GROUP="student", MODE="0600"
[root@station9 disk]# partprobe /dev/sdb
[root@station9 disk]# ll /dev/sdb
brw------- 1 student student 8, 16 Nov 29 15:52 /dev/sdb
3.- iSCSI
El driver iSCSI provee al host la habilidad de acceder al almacenamiento a través que una red IP. El
driver usa el protocolo iSCSI (definido por IETF) para transportar las peticiones y respuestas SCSI sobre
una red IP entre el host y el dispositivo target iSCSI. A nivel de arquitectura, el driver iSCSI se combina
con la pila TCP/IP del host, los drivers de red y las tarjetas de red (NIC) para proveer las mismas
funciones que SCSI o un adapatador de fibra (FC) con un HBA.
Los clientes (initiators) envían comandos SCSI a dispositivos de almacenamiento remotos (targets)
usando TCP/IP (puerto tcp:3260, por defecto).
Initiator
• Peticiones a dispositivos de bloques remotos vía procesos de descubrimiento.
• Se requiere que el driver iSCSI esté cargado.
• El servicio iscsi habilita la persistencia de dispositivos targets.
• Paquete: iscsi-initiator-utils-*.rpm

Target (en este caso, usaremos un RHEL como servidor iSCSI, en el mundo real, tendremos una cabina
de discos, esto no sería necesario)
• Exporta uno más dispositivos de bloques para que los clientes (initiators) accedan
• Soportado desde RHEL 5.3
• Paquete: scsi-target-utils-*.rpm
Un dispositivo iniciador (cliente) es el que busca e interactúa con dispositivos targets, mientras que un
target es un dispositivo pasivo.
El host ID es único para cada target. El LUN ID es asignado por el target iSCSI, cuyo driver provee
un transporte para las peticiones y respuestas SCSI a dispositivos de almacenamiento via red IP, en
vez de usar un bus SCSI directamene anexado o una conexión FC. El router de almacenamiento, en
cambio, transporta esas peticiones y respuestas SCSI a través de las redes IP y los dispositivos de
almacenamiento anexados a él. Una vez que el driver iSCSI está instalado, el host procederá a realizar
el proceso de descubrimiento de dispositivos de almacenamiento de la siguiente manera:
• Las peticiones del driver iSCSI a targets disponibles a través de un mecanismo de descubrimiento
usan la configuración del fichero /etc/iscsi/iscsid.conf.
• Cada target iSCSI envia los nombres de targets iSCSI disponibles al driver iSCSI.
• El target iSCSI acepta el login y envía los identificadores de targets.
• El driver iSCSI pregunta a los target la información de los dispositivos.
• Los targets responden con la información del dispositivo.
• El driver iSCSI crea una tabla de dispositivos target disponibles.
Una vez que la tabla está completada, los targets iSCSI están disponibles para usarse por los hosts
usando los mismos comandos y utilidades que si estuvieran directamente conectados a un dispositivo
de almacenamiento.
El driver iSCSI usa los nombres por defecto del kernel para cada dispositivo iSCSI de la misma manera
que lo haría cualquier otro dispositivo SCSI y tranporte como FC/SATA.
Puesto que Linux asigna los nodos de dispositivos SCSI cada vez que una unidad lógica SCSI se
detecta, el mapeo a nodos de dispositivos a targets iSCSI y unidades lógicas puede variar. Por tanto, es
necesario que hayan nombres de dispositivos persistentes, para lo que usaremos udev. El comando
scsi_id provee el SN para un dispositivo de bloques dado, al integrarse con udev, puede usarse para
crear un nombre persistente.
*Importante* en /etc/fstab hay que añadir la opción: _netdev, sin ella, rc.sysinit intentará
montar el targe antes de tener capacidades de red o de que los servicios iscsid se hayan arrancado.
El formato de nombres de los targets iSCSI requiere que se empiece con un tipo de designación (por
ejemplo ‘iqn’ para ‘iSCSI Qualified Name’) y debe seguirse por varios campos separados de ‘-’ creando
así un nombre único global. El formato de sub campos IQN es el siguiente:
• Tipo de designador requerido (iqn)
• Fecha de alta (yyyy-mm)
• Nombre de dominio en reverso (tld.domain)
• Cualquier cadena que asegure unicidad (string[[.string]...])
• De manera opcional, cadenas de sub grupos delimitadas por ‘:’ ([:substring])

Por tanto el formato de cadena IQN (único de manera global) serát:
iqn.<date_code>.<reversed_domain>.<string>[:<substring>]
Ejemplo:
iqn.2007-01.com.example.sales:sata.rack2.disk1
Los pasos para configurar los targets:

1. Instalar el paquete scsi-target-utils.
2. Modificarel fichero /etc/tgt/targets.conf.
3. Arrancar el servicio tgtd.
4. Verificar la configuración con tgt-admin -s
5. Reprocesar la configuración con tgt-admin --update
• No es posible cambiar los parámetros de un target ocupado de esta forma
• Usar tgtadm (script perl de bajo nivel) en su lugar.
El fichero /etc/tgt/targets.conf tiene las siguientes opciones principales:
Parámetro Descripción
backing-store device defines a virtual device on the target.
direct-store device creates a device that with the same VENDOR_ID and
SERIAL_NUM as the underlying storage
initiator-address address Limits access to only the specified IP address. Defaults

to all
incominguser username Only specified user can connect.

password
outgoinguser username password Target will use this user to authenticate against the
initiator.
Ejemplo:
<target iqn.2009-10.com.example.cluster20:iscsi>
# List of files to export as LUNs
backing-store /dev/vol0/iscsi
initiator-address 172.17.120.1
</target>
NOTA: Si no especifico ningún initiator, se entiende que permito que cualquiera se pueda conectar al
target iSCSI.
3.1. CONFIGURACIÓN DEL CLIENTE (iSCSI INITIATOR)
El fichero de configuración del cliente es /etc/iscsi/iscsid.conf. La configuración por defecto

funciona sin modificaciones (por defecto no hay autenticación).

Configuración básica del fichero /etc/iscsi/iscsid.conf es:
• Startup - automática o manual
• CHAP - usuarios y claves de acceso
• Timeouts - conexiones, login / logout
• iSCSI - control de flujo, tamaño de carga, comprobación de digest
Para descubrir / conectarnos a un target usamos iscsiadm (necesita que esté corriendo iscsi)
• Utilidad de gestión open-iscsi.
• Gestiona el descubrimiento y login a targets iSCSI.
• Gestiona el acceso y configuración de la base de datos open-iscsi.
• Muchas operaciones requieren que el demonio iscsid esté ejecutandose.
Los ficheros de configuración son:

• /etc/iscsi/iscsid.conf: Fichero principal de configuración. Se lee en el arranque de
iscsid y iscsiadm.
• /etc/iscsi/initiatorname.iscsi: Establece el nombre (InitiatorName) y alias
(InitiatorAlias) del initiator. Leido por iscsid y iscsiadm en el arranque.
• /var/lib/iscsi/nodes/: Información del node y target.
• /var/lib/iscsi/send_targets: Informatión del portal
3.2. CONEXIÓN POR PRIMERA VEZ A UN TARGET iSCSI
1. Iniciar el servicio initiator (el demonio):

# service iscsi start
2. Descubrir los targets disponibles:
# iscsiadm -m discovery -t sendtargets -p 172.16.36.1:3260 172.16.36.71:3260,1
iqn.2007-01.com.example:storage.disk1
3. Login en la sesión target:
# iscsiadm -m node -T iqn.2007-01.com.example:storage.disk1 -p 172.16.36.1:3260 -l
4. Ver la información sobre los targets:
# iscsiadm -m node -P N (N=0,1)
# iscsiadm -m session -P N (N=0-3)
# iscsiadm -m discovery -P N (N=0,1)
En /var/lib/iscsi se guardan todos los ficheros de configuración del cliente, por tanto si he de
borrar un dispositivo y no sé cómo hacerlo, borrar todos los ficheros / directorios de este directorio
nos puede servir de ayuda.
Para borrar el registro del target:

# iscsiadm -m node -o delete -T iqn.2007-01.com.example:storage.disk1 -p
172.16.36.1:3260
Ejercicios:
1.Configurar un target iSCSI en nuestra máquina local.
[root@station9 ~]# yum install -y scsi-target-utils
[root@station9 ~]# lvcreate vol0 -n iscsi -L 5G
Logical volume "iscsi" created
[root@station9 ~]# vi /etc/tgt/targets.conf

</target>
[root@station9 ~]# service tgtd start
[root@station9 ~]# chkconfig tgtd on
Comprobamos que el volumen target iSCSI se ha exportado al host correcto:
[root@station9 ~]# tgt-admin -s
Target 1: iqn.2010-11.com.example.cluster9:iscsi
System information:
Driver: iscsi
State: ready
I_T nexus information:
LUN information:
LUN: 0
Type: controller
SCSI ID: deadbeaf1:0
SCSI SN: beaf10
Size: 0 MB
Online: Yes
Removable media: No
Backing store: No backing store
LUN: 1
Type: disk
SCSI ID: deadbeaf1:1
SCSI SN: beaf11
Size: 5369 MB
Online: Yes
Removable media: No
Backing store: /dev/vol0/iscsi
Account information:
ACL information:
172.17.109.1
172.17.109.2
172.17.109.3
2. Configurar los nodos clientes

[root@node1 ~]# echo "InitiatorAlias=node1" >> /etc/iscsi/initiatorname.iscsi
[root@node1 ~]# service iscsi start
[root@node1 ~]# chkconfig iscsi on
Buscamos todos los targets disponibles para mi máquina en el portal 172.17.109.254
[root@node1 ~]# iscsiadm -m discovery -t sendtargets -p 172.17.109.254
172.17.109.254:3260,1 iqn.2010-11.com.example.cluster9:iscsi
Vemos la información sobre el target recién descubierto:
[root@node1 ~]# iscsiadm -m node -T iqn.2010-11.com.example.cluster9:iscsi -p
172.17.109.254
# BEGIN RECORD 2.0-871
node.name = iqn.2010-11.com.example.cluster9:iscsi
node.tpgt = 1
node.startup = automatic
iface.hwaddress = <empty>
iface.ipaddress = <empty>

iface.iscsi_ifacename = default
iface.net_ifacename = <empty>
iface.transport_name = tcp
iface.initiatorname = <empty>
node.discovery_address = 172.17.109.254
node.discovery_port = 3260
node.discovery_type = send_targets
node.session.initial_cmdsn = 0
node.session.initial_login_retry_max = 8
node.session.xmit_thread_priority = -20
[...]
# END RECORD
Toda esta información se encuentra en el directorio /var/lib/iscsi
Hacemos login en el target iSCSI
172.17.109.254 -l
Logging in to [iface: default, target: iqn.2010-11.com.example.cluster9:iscsi,
portal: 172.17.109.254,3260]
Login to [iface: default, target: iqn.2010-11.com.example.cluster9:iscsi, portal:
172.17.109.254,3260]: successful
Comprobamos que el disco está disponible:
[root@node1 ~]# fdisk -l
[...]
Disk /dev/sda: 5368 MB, 5368709120 bytes
166 heads, 62 sectors/track, 1018 cylinders
Units = cylinders of 10292 * 512 = 5269504 bytes
Borramos el target iSCSI
172.17.109.254 -o delete
Crear una nueva partición, formatearla, crear un directorio, escribir en él añadirlo al fstab y reiniciar
para comprobar su persistencia.
[root@node1 ~]# mkdir /mnt/class
[root@node1 ~]# fdisk /dev/sda
[...]
[root@node1 ~]# partprobe
[root@node1 ~]# mkfs.ext3 /dev/sda1
[root@node1 ~]# echo "/dev/sda1 /mnt/class ext3 _netdev 0 0" >> /etc/fstab
[root@node1 class]# dd if=/dev/zero of=fichero_test bs=1M count=10
3. Crear una regla udev en node1

[root@node1 class]# scsi_id -g -u -s /block/sda
S_beaf11
[root@node1 class]# vi /etc/udev/rules.d/75-classlab_remote.rules
KERNEL=="sda[1-9]", PROGRAM=="scsi_id -g -u -s /block/sda/sda%n", RESULT="S_beaf11",
SYMLINK="iscsi%n"
[root@node1 class]# partprobe
4.- REDUNDANT ARRAY OF INEXPENSIVE DISKS
Redundant Array of Inexpensive Disks, («conjunto redundante de discos baratos») hace referencia

a un sistema de almacenamiento que usa múltiples discos duros entre los que distribuye o replica los
datos. Dependiendo de su configuración (a la que suele llamarse «nivel»), los beneficios de un RAID
respecto a un único disco son uno o varios de los siguientes: mayor integridad, mayor tolerancia a
fallos, mayor throughput (rendimiento) y mayor capacidad.
En este curso veremos RAID por sofware únicamente. Linux soporta los niveles RAID 0, 1, 5, 6 y 1+0.
Usaremos la herramienta mdadm.
● RAID 0: Conjunto dividido

Un RAID 0 (también llamado conjunto dividido o volumen dividido) distribuye
los datos equitativamente entre dos o más discos sin información de paridad que
proporcione redundancia.
Para crear un RAID 0 por software:

#mdadm --create /dev/md0 --level=0 --raid-devices=2 --chunk=64 /dev/sd[ab]1
#mke2fs -j 4096 -E stride=16 /dev/md0
El stride es el resultado de dividir el chunk entre el tamaño de bloques en kb (64/4=16). Esto se
hace para obtener el mejor rendimiento.
● RAID 1: Conjunto en espejo
Un RAID 1 crea una copia exacta (o espejo) de un conjunto de datos en dos o más discos. Esto
resulta útil cuando el rendimiento en lectura es más importante que la capacidad. Un conjunto
RAID 1 sólo puede ser tan grande como el más pequeño de sus discos. La desventaja es que se
desperdicia mucho espacio.

#mdadm --create /dev/md0 --level=1 --raid-devices=2 /dev/sd[ab]1
Podemos simular un disco fallado y su proceso de reemplazo con mdadm:
#mdadm --mange /dev/md1 --fail /dev/sda
#mdadm --mange /dev/md1 --remove /dev/sda
#mdadm --mange /dev/md1 --add /dev/sdd
● RAID 5: Conjunto dividido con paridad distribuida
Un RAID 5 usa división de datos a nivel de bloques distribuyendo la información de paridad
entre todos los discos miembros del conjunto. Generalmente, el RAID 5 se implementa con
soporte hardware para el cálculo de la paridad. RAID 5 necesitará un minimo de 3 discos para
ser implementado. Para el cálculo de paridad, el RAID 5 usa una función XOR.

#mdadm --create /dev/md0 --level=5 --raid-devices=3 /dev/sd[abc]1
También se puede especificar la paridad de un RAID5 a la hora de crearlo (por defecto es
simétrico por la izquierda, pues favorece las lecturas secuenciales).
● RAID 6: Un RAID 6 amplía el nivel RAID 5 añadiendo otro bloque de paridad, por lo que
divide los datos a nivel de bloques y distribuye los dos bloques de paridad entre todos los
miembros del conjunto. El RAID 6 es ineficiente cuando se usa un pequeño número de discos
pero a medida que el conjunto crece y se dispone de más discos la pérdida en capacidad de
almacenamiento se hace menos importante, creciendo al mismo tiempo la probabilidad de que
dos discos fallen simultáneamente. El RAID 6 proporciona protección contra fallos dobles de
discos y contra fallos cuando se está reconstruyendo un disco. En caso de que sólo tengamos
un conjunto puede ser más adecuado que usar un RAID 5 con un disco de reserva (hot spare).

#mdadm --create /dev/md0 --level=6 --raid-devices=4 /dev/sd[abcd]1
● RAIDs Anidados: Los niveles RAID anidados más comúnmente usados son:
● RAID 0+1: Un espejo de divisiones.
Un RAID 0+1 es un RAID usado para replicar y compartir datos entre varios discos.
La diferencia entre un RAID 0+1 y un RAID 1+0 es la localización de cada nivel RAID
dentro del conjunto final: un RAID 0+1 es un espejo de divisiones. El problema es que
al perder uno de los discos del nivel 0, pierdo los dos, tengo que buscar los datos en el
otro RAID 0.
Para crear un RAID 0+1 por software:

#mdadm --create /dev/md1 --level=0 --raid-devices=2 --chunk=64 /dev/sd[ab]1
#mdadm --create /dev/md2 --level=0 --raid-devices=2 --chunk=64 /dev/sd[cd]1
#mdadm --create /dev/md0 --level=1 --raid-devices=2 /dev/md[12]
● RAID 1+0: Una división de espejos
Un RAID 1+0, a veces llamado RAID 10, es parecido a un RAID 0+1 con la excepción de
que los niveles RAID que lo forman se invierte: el RAID 10 es una división de espejos.
Aunque se pierda un disco del nivel 1, todos los demás discos siguen dando servicio. Es
mucho más fiable.

En Linux podemos crear un RAID 10 en un único paso (por eso se llama 10 y no 1+0), a
diferencia del resto de RAIDS anidados.
#mdadm --create /dev/md0 --level=10 --raid-devices=4 /dev/sd[abcd]1
Podemos obtener información (o modificar acciones) de nuestro RAID con el comando mdstat o bien
en el /proc/mdstat o bien en /sys/block/mdX/md:
<ejemplos aqui>
4.1 DISCOS DE RESERVA
Se pueden añadir discos en los que no se esté escribiendo al RAID para utilizarse como discos de
repuesto, así pues, cuando falla un disco, el RAID automáticamente lo reemplazará y realizará su
sincronización con el resto del RAID. Estos discos se pueden compartir entre distintos RAIDs; esto se
consigue con el fichero /etc/mdadm.conf. Éste no es el fichero de configuración de los arrays, ésta
está dentro del propio array.
Primero ejecutamos un escaneo, para buscar arrays en el sistema:

# mdadm --verbose --examine --scan
Podemos buscar la documentación del mdadm para ayudarnos:
[root@node1 class]# rpm -qf /sbin/mdadm
mdadm-2.6.9-2.el5
[root@node1 class]# rpm -qd mdadm-2.6.9-2.el5
/usr/share/doc/mdadm-2.6.9/ANNOUNCE-2.0
[...]
/usr/share/doc/mdadm-2.6.9/mdadm.conf-example
[...]
[root@node1 class]# chkconfig mdmonitor on
[root@node1 class]# service mdmonitor start
NOTA: este servicio no arrancará a menos que en el fichero /etc/mdadm.conf exista la directiva
MAILADDR root@mydomain.tld
Para poder chequear una única vez nuestro array:

[root@node1 class]# mdadm --monitor --scan --oneshot --test
En Linux se pueden reorganizar o redimensionar varios parámetros del array:

Número de dispositivos
Chunck
Organización de los datos

Paridad / tipo de ubicación
Para realizar cualquiera de estas operaciones, es necesario realizar un backup de la sección crítica. La
manera de hacerlo es añadir el parámetro backup-file:
# mdadm --grow /dev/mdX --raid-devices=4 --backup-file=/tmp/mdX.backup
Ejemplos:
Redimensionar / redefinir un stripe de datos:
# mdadm --grow /dev/md0 --raid-devices=4 --backup-file=/tmp/md0-backup
Si la sección crítica se ha corrompido, la única manera de recrearlo es con un backup:
# mdadm --assemble /dev/md0 --backup-file=/tmp/md0-backup /dev/sd[a-d]
Ejercicios
1. Crear un RAID 1 (mirror) con las 2 primeras particiones y otro RAID1 con las otras dos, pero con
bitmap write-intent
# fdisk -l
/dev/sda7 4212 4273 498014+ fd Linux raid autodetect
[root@station9 ~]# partprobe
[root@station9 ~]# mdadm --create /dev/md0 --level=1 --raid-devices=2 /dev/sda{7,8}
--auto=yes
mdadm: array /dev/md0 started.
[root@station9 ~]# mdadm --create /dev/md1 --level=1 --raid-devices=2 /dev/
sda{9,10} --auto=yes -b internal
[root@station9 ~]# mkdir /data0 /data1
[root@station9 ~]# mkfs -t ext3 /dev/md0
[root@station9 ~]# mkfs -t ext3 /dev/md1
Para monitorizar el RAID:
[root@station9 ~]# watch -n .2 'cat /proc/mdstat'
Personalities : [raid1]
md1 : active raid1 sda10[1] sda9[0]
497920 blocks [2/2] [UU]
497920 blocks [2/2] [UU]
unused devices: <none>
Simulamos fallos en los arrays:
[root@station9 ~]# mdadm /dev/md0 --fail /dev/sda7 --remove /dev/sda7
mdadm: set /dev/sda7 faulty in /dev/md0
mdadm: hot removed /dev/sda7
md0 : active raid1 sda8[1]
497920 blocks [2/1] [_U]
[root@station9 ~]# dd if=/dev/urandom of=/data0/fichero bs=1M count=10
10+0 records in
10+0 records out
10485760 bytes (10 MB) copied, 2.10135 seconds, 5.0 MB/s
[root@station9 ~]# mdadm /dev/md0 --add /dev/sda7
mdadm: re-added /dev/sda7

497920 blocks [2/1] [_U]
[==============>......] recovery = 74.1% (370368/497920) finish=0.0min
speed=23148K/sec
2. Crear 3 particiones de 100M en el nodo1 del cluster y crear un RAID5

/dev/hda5 340 352 104391 fd Linux raid autodetect
[root@node1 ~]# partprobe
[root@node1 ~]# mdadm --create /dev/md0 --level=5 --raid-devices=3 /dev/hda{5,6,7}
[root@node1 ~]# mkfs -t ext3 -L raid5 /dev/md0
[root@node1 ~]# mkdir /raid5
[root@node1 ~]# mount LABEL=raid5 /raid5
[root@node1 ~]# mdadm --detail /dev/md0 |grep -i chunk
Chunk Size : 64K
[root@node1 ~]# cp /usr/share/dict/words /raid5/
[root@node1 ~]# echo "raid5" > /raid5/prueba
[root@node1 ~]# watch -n .2 'cat /proc/mdstat'
Every 0.2s: cat /proc/mdstat
Tue Nov 30 12:44:40 2010
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 hda7[2] hda6[1] hda5[0]
208640 blocks level 5, 64k chunk, algorithm 2 [3/3] [UUU]
Ahora fallamos y verificamos el RAID5.
[root@node1 ~]# mdadm /dev/md0 --fail /dev/hda5 --remove /dev/hda5
mdadm: set /dev/hda5 faulty in /dev/md0
mdadm: hot removed /dev/hda5
Tue Nov 30 12:47:12 2010
md0 : active raid5 hda7[2] hda6[1]
208640 blocks level 5, 64k chunk, algorithm 2 [3/2] [_UU]
Tue Nov 30 12:48:28 2010
md0 : active raid5 hda7[2]
208640 blocks level 5, 64k chunk, algorithm 2 [3/1] [__U]
Podemos leer ficheros que estén cacheados, pero no podemos escribir una vez fallan 2 discos, el
sistema lo marca como solo lectura.
[root@node1 ~]# touch /raid5/algo
touch: cannot touch `/raid5/algo': Read-only file system
Aunque no podremos recuperar el dispositvo al volver a añadir el disco. Intentar volver a ensamblar
el dispositivo lo que devolverá un mensaje indicando que no hay suficientes dispositivos válidos para
arrancaer el aray.

[root@node1 ~]# mdadm /dev/md0 --add /dev/hda5
mdadm: re-added /dev/hda5
Tue Nov 30 13:02:35 2010
md0 : active raid5 hda5[0](S) hda7[2]
208640 blocks level 5, 64k chunk, algorithm 2 [3/1] [__U]
[root@node1 ~]# umount /dev/md0
[root@node1 ~]# mdadm --stop /dev/md0
mdadm: stopped /dev/md0
[root@node1 ~]# mdadm --assemble /dev/md0 /dev/hda{5,6,7} --force
mdadm: forcing event count in /dev/hda6(1) from 8 upto 16
mdadm: /dev/md0 has been started with 2 drives (out of 3).
Creamos un RAID6 con otras 4 particiones
[root@node1 ~]# fdisk -l /dev/hda
[root@node1 ~]# mdadm --create /dev/md1 --level=6 --raid-devices=4 /dev/
hda{8,9,10,11} --auto=yes
Tue Nov 30 13:08:30 2010
md1 : active raid6 hda11[3] hda10[2] hda9[1] hda8[0]
208640 blocks level 6, 64k chunk, algorithm 2 [4/4] [UUUU]
[=====>...............] resync = 27.4% (29208/104320) finish=0.7min
speed=1622K/sec
[root@node1 ~]# pvcreate /dev/md1
Physical volume "/dev/md1" successfully created
[root@node1 ~]# vgcreate vgraid /dev/md1
Volume group "vgraid" successfully created
[root@node1 ~]# vgdisplay vgraid |grep -i free
Free PE / Size 50 / 200.00 MB
[root@node1 ~]# lvcreate --extents=50 --name=lvraid vgraid
Logical volume "lvraid" created
[root@node1 ~]# mkfs -t ext3 -L raid6 /dev/vgraid/lvraid
[root@node1 ~]# mkdir /raid6
[root@node1 ~]# mount LABEL=raid6 /raid6
[root@node1 ~]# echo "raid6" > /raid6/prueba
Fallamos y quitamos dispositivos
Tue Nov 30 13:16:25 2010
md1 : active raid6 hda11[3] hda10[2]
208640 blocks level 6, 64k chunk, algorithm 2 [4/2] [__UU]

[root@node1 ~]# cat /raid6/prueba
raid6
[root@node1 ~]# touch /raid6/hola
Recuperamos los discos del array
3. Crear el fichero /etc/mdadm.conf en el nodo1 con la información disponible.

[root@node1 ~]# mdadm --examine --verbose --scan > /etc/mdadm.conf
[root@node1 ~]# cat /etc/mdadm.conf
ARRAY /dev/md0 level=raid5 num-devices=3 UUID=7d0da1d3:49b32c29:cd4a22e3:eebfa7c2
devices=/dev/hda7,/dev/hda6,/dev/hda5 spare-group=amaya
ARRAY /dev/md1 level=raid6 num-devices=4 UUID=7ca3b11a:62882f07:6829a892:46d7762a
devices=/dev/hda11,/dev/hda10,/dev/hda9,/dev/hda8 spare-group=amaya
MAILADDR root
Creamos una nueva partición y la añadimos como hot spare
mdadm: added /dev/hda12
Tue Nov 30 13:24:49 2010
md0 : active raid5 hda12[3](S) hda5[0] hda6[1] hda7[2]
Configurar mdmonitor
[root@node1 ~]# vi /etc/mdadm.conf
MAILADDR root
[root@node1 ~]# chkconfig mdmonitor on
[root@node1 ~]# service mdmonitor restart
Automáticamente el disco hot spare del RAID5 ha migrado al RAID6.
Tue Nov 30 13:30:55 2010
md1 : active raid6 hda12[4] hda9[1] hda11[3] hda10[2]
208640 blocks level 6, 64k chunk, algorithm 2 [4/3] [_UUU]
[======>..............] recovery = 32.3% (34652/104320) finish=0.4min
speed=2887K/sec
md0 : active raid5 hda5[0] hda6[1] hda7[2]
4. Borrar cualquier partición existente en nuestra SAN (/dev/sda) en el nodo1 y crear 4 particiones de
1Gb.
[root@node1 ~]# fdisk -l /dev/sda
Device Boot Start End Blocks Id System
/dev/sda1 1 191 982855 fd Linux raid autodetect
/dev/sda4 574 1018 2289970 5 Extended
Fallar uno a uno todos los discos locales, deespués de ir añadiendo discos SAN hot spare, para migrar
asi todos los datos

[root@node1 ~]# mdadm /dev/md1 --add /dev/sda1
mdadm: added /dev/sda1
Tue Nov 30 13:46:10 2010
md1 : active raid6 sda5[4] sda3[2] sda2[3] sda1[1]
208640 blocks level 6, 64k chunk, algorithm 2 [4/3] [_UUU]
[=============>.......] recovery = 69.6% (72960/104320) finish=0.1min
speed=3648K/sec
Crecer el RAID6 para aprovechar todo el espacio
[root@node1 ~]# mdadm --grow /dev/md1 --size=max
Tue Nov 30 13:47:46 2010
md1 : active raid6 sda5[0] sda3[2] sda2[3] sda1[1]
1965568 blocks level 6, 64k chunk, algorithm 2 [4/4] [UUUU]
[==>..................] resync = 13.7% (135616/982784) finish=7.2min
speed=1956K/sec
[root@node1 ~]# mdadm --detail /dev/md1 | grep -i size
Array Size : 1965568 (1919.82 MiB 2012.74 MB)
Used Dev Size : 982784 (959.91 MiB 1006.37 MB)
Chunk Size : 64K
Hay que redimensionar también el volumen físico
[root@node1 ~]# vgdisplay vgraid | grep -i size
VG Size 1.87 GB
PE Size 4.00 MB
Alloc PE / Size 50 / 200.00 MB
Free PE / Size 429 / 1.68 GB
[root@node1 ~]# lvresize --extents=+100%FREE /dev/vgraid/lvraid
Extending logical volume lvraid to 1.68 GB
Logical volume lvraid successfully resized
VG Size 1.87 GB
PE Size 4.00 MB
Alloc PE / Size 479 / 1.87 GB
Free PE / Size 0 / 0

VG Size 1.87 GB
PE Size 4.00 MB
Alloc PE / Size 479 / 1.87 GB
Free PE / Size 0 / 0
Por último hay que agrandar el sistema de ficheros subyacente
[root@node1 ~]# resize2fs /dev/vgraid/lvraid
[root@node1 ~]# df -Th |grep raid6
ext3 1.9G 6.8M 1.8G 1% /raid6
5.- DEVICE MAPPER
El objetivo de este driver es posibilitar la gestión de volúmenes. El driver permite la creación de

nuevos dispositivos de bloques lógicos compuestos de rangos de sectores desde un dispositivo de
bloques físico existente, de manera arbitraria. Esto puede usarse para definir particiones de discos o
volúmenes lógicos. Este componente del kernel admite herramientas del espacio de usuario para la
gestión de volúmenes lógicos. Los dispositivos mapeados pueden ser mayores de 2Tb en las últimas
versiones del kernel 2.6.
Device mapper tiene una biblioteca de espacio de usuario (libdm) que es la que usan de interfaz
las aplicaciones de gestión de volúmenes / dispositivos (como por ejemplo dmraid, LVM2) y una
herramienta de configuración llamada dmsetup. La biblioteca libdm crea los nodos a dispositivos
mapeados en /dev/mapper.
Cada metadispositivo mapeado se define en un fichero de texto basado en una tabla de reglas
ordenadas que mapean cada sector (512 bytes) del dispositivo lógico a su correspondiente sector
arbitrario del dispositivo físico.
Cada entrada de la tabla tiene el siguiente formato:

logicalStartSector numSectors targetType targetArgs [...]
[root@node1 ~]# vi amaya.table

0 30 linear /dev/sda 0
30 40 linear /dev/sdb 0
70 10 linear /dev/sdc 0
Cada una de estas líneas se lee: “empezando en el bloque 0 y ocupando 30 bloques, escribe de manera
lineal en /dev/sda empezando en su bloque 0”.
Para poder gestionar / ver la tabla usaremos el comando dmsetup:

[root@node1 ~]# dmsetup table
VolGroup00-LogVol00: 0 4128768 linear 3:2 384
Los targets del device mapper (dmsetup targets) son:

• linear: Ubicación contigua de los datos.
• striped: Ubicación segmentada a través de los dispositivos.
• error: Defines el área "fuera de límite”.

• snapshot: Dispositivo copy-on-write.
• snapshot-origin: Dispositivo de mapeo de un volumen original.
• zero: Dispositivo de bloques disperso (generador de ceros).
• multipath: Rutas alternativas de E/S a un dispositivo.
5.1. SNAPSHOTS LVM2
Las instantáneas (snapshots) permiten al administrador crear un nuevo dispositivo que será una
copia exacta del LV, congelada en algún punto del tiempo. Normalmente esto se realiza de forma
automática, para no alterar el funcionamiento normal del sistema. Cuando la instantánea ha
terminado, el administrador puede quitar el dispositivo sin mayor complicación.
Una diferencia importante entre la versión 1 de LVM y la versión 2 es que en la primera, los snapshots
eran de sólo lectura, mientras que en LVM2 son de lectura y escritura. En LVM1, se crea una tabla de
excepciones, que se usa para mantener una lista de qué bloques en disco han cambiado. Si un bloque
va a ser modificado en el origen, primero se copia en la instantánea, se marca como copiado en la
tabla de excepciones y luego los nuevos datos se copian al volumen original. En LVM2, las instantáneas
funcionan como en LVM1, pero con la característica de que si los datos se escriben en el snapshot (una
vez montado), ese bloque se marca como usado en la tabla de excepciones y no se copia al volumen
original. Esta característica es muy útil debido a que podemos crear nuestra instantánea, montarla y
probar un programa o un nuevo navegador de ficheros. Si ocurre algo desastroso, la desmontamos, la
borramos y volvemos a colocar el volumen original.
Un snapshot no es un backup, puesto que no copia ningún dato, sino que mantiene una tabla de
inodos a los datos en el momento del snapshot. El úso más típico es usar los snapshots como paso
intermedio para hacer un backup, pues en vez de parar, obtenemos un snapshot y de ahí su backup
(obviamente, en caso de no tener un software de backup sofisticado).
Para realizar un snapshot necesitamos tener cargado el driver dm-snapshot. Este driver trabaja junto
con snapshot-origin y copia los datos del dispositivo de origen a un dispositivo de bloques copy-
on-write (COW) separado para almacenamiento antes de la modificación. Los snapshots se leen del
dispositivo COW o del origen subyacente para datos que no hayan sido modificados.
Los parámetros que puede usar un snapshot son:

• Origin device (dispositivo de orgien): El dispositivo original subyacente que está
siendo “snapshoteado”.
• COW device (dispositivo COW): Cualquier bloque escrito al volumen de snapshot se almacena aquí.
La versión original de los bloques cambiados o el volumen original también se almacenan aquí.
• persistent? (¿es persistente?): Si sibrevive a un reboot ‘P’ (por defecto), sino ‘N’. Si este es un
snapshot temporal, es preferible usar ‘N’ puesto que los metadatos pueden mantenerse en memoria
por el kernel en vez de tener que grabarlos a disco.
• chunk size (tamaño de pieza): Piezas de datos de tamaño “chunk size” modificadas (por defecto 16
sectores, u 8Kb) que se almacenarán en el dispositivo COW.
Cuando se crea un snapshot LVM2, se usan 4 dispositivos dm:

• El mapeo original del volumen fuente de datos (<name>-real).

• Un mapeo snapshot del volumen original (snapshot-origin).
• El dispositivo COW (snapshot)
• El dispositivo snapshot visible, que consite en el primero y tercero (<name>)
• Permite que el dispositivo de bloques se mantenga en modo escritura, sin alterar los daots
originales.
Por ejemplo, crear un volumen lógico:

# pvcreate /dev/sdb1
# vgcreate vg0 /dev/sdb1
# lvcreate -L 500M -n original vg0
Hacer un snapshot de dicho volumen:
# lvcreate -L 100M -n snap --snapshot /dev/vg0/original
Comprobar la creación del snapshot:
# ll /dev/mapper | grep vg0
total 0
brw-rw---- 1 root disk 253, 0 Mar 21 12:28 vg0-original
brw-rw---- 1 root disk 253, 2 Mar 21 12:28 vg0-original-real
brw-rw---- 1 root disk 253, 1 Mar 21 12:28 vg0-snap
brw-rw---- 1 root disk 253, 3 Mar 21 12:28 vg0-snap-cow
# dmsetup table | grep vg0 | sort

vg0-original: 0 1024000 snapshot-origin 253:2
vg0-original-real: 0 1024000 linear 8:17 384
vg0-snap: 0 1024000 snapshot 253:2 253:3 P 16
vg0-snap-cow: 0 204800 linear 8:17 1024384
# dmsetup ls --tree
vg0-snap (253:1)
|_vg0-snap-cow (253:3)
|
\_(8:17)
\_vg0-original-real (253:2)
\_(8:17)
vg0-original (253:0)
\_vg0-original-real (253:2)
\_(8:17)
5.2. MULTIPATHING
Es una metodología de acceso a disco. En principio surgió como una implementación de acceso SCSI
por múltiples vías. Conforma una capa de conmutación para distintos caminos al mismo dispositivo de
almacenamiento.
Device Mapper Multipath provee redundancia, cuando falla un camino y hay otro camino disponible,
dm-multipath re-enruta la E/S sobre los caminos disponibles. Cuando hay varios caminos a un
almacenamiento, cada camino aparece como un dispositivo separado. Device Mapper Multipath crea
un metadispositivo por encima de esos dispositivos. Por ejemplo, un nodo con 2 HBAs, cada una de las
cuales tiene 2 puertos anexados a una controladora de almacenamiento, ve 4 dispositivos: /dev/sda,
/dev/sdb, /dev/sdc, y /dev/sdd. Device mapper multipath crea un único dispositivo, /dev/dm-2

(por ejemplo) que re-enruta la E/S a esos 4 dispositivos subyacentes.
Las soluciones de multipathing existentes no son complementarias, si usamos la de Linux (device

mapper multipath) no usaremos EMC Powerpath, por ejemplo.
Device Mapper Multipath es independiente del fabricante y la tecnología subyacente (por ejemplo, se
puede tener un camino de FC y otro iSCSI); además es “cluster aware”.
5.3. COMPONENTES DEL DEVICE MAPPER MULTIPATH
Los componentes de Device Mapper Multipath son los siguientes:

• Grupos de prioridad multipath.
• Módulo del kernel dm-multipath.
• multipath: lista y configura los dispositivos multipath.
• demonio multipathd: monitoriza los caminos.
• kpartx: crea dispositivos dm para las particiones.
5.3.1 GRUPOS DE PRIORIDAD

Los diferentes caminos a un almacenamiento compartido se organizan dentro de grupos de prioridad,
cada uno con una prioridad asignada (0-1024), cuanto menor sea la prioridad, mayor preferencia
tendrá ese grupo. Si un camino falla, la E/S se envía al grupo de prioridad con mayor prioridad de los
disponibles (número más bajo), y así sucesivamente. Sólo un grupo de prioridad está activo en cada
momento (el de mayor prioridad).
La acción a ejecutarse cuando falla uno de los grupos de prioridad, se configura con el parámetro
path_grouping_policy el la sección “defaults” del fichero /etc/multipath.conf. Este parámetro se
suele configurar con el valor de failover.
Colocar más de un camino en el mismo grupo de prioridad nos da una configuración “activo/activo”
mientras que separar los caminos en distintos grupos de prioridad da una configuración “activo/
pasivo”, es decir, los caminos activos están en uso, mientras que los caminos pasivos se mantienen
inactivos hasta que se necesiten debido a un fallo en el camino activo. Requiere el driver dm-
multipath.
Los parámetros (después de la palabra multipath) son: <num_pg> <sched> <num_paths>

<num_paths_parms> <path_list> [<sched> <num_paths> <num_paths_parms> <path_list>]...
Siendo estos parámetros:
<num_pg>: Número de grupos de prioridad.
<sched>: El planificador usado para expandir la E/S dentro del grupo de prioridad.
<num_paths>: Número de caminos en el grupo de prioridad.
<num_paths_parms>: Número de parámetros de caminos en el grupo de prioridad (generlamente 0).
<path_list>: Lista de caminos para este grupo de prioridad.
Ejemplos:

Almacenamiento de 1Gb con 2 grupos de prioridad, cada grupo usa round-robin para repartir la E/S
entre los 2 caminos:
0 2147483648 multipath 2 round-robin 2 0 /dev/sda /dev/sdb round-robin 2 0 /
dev/sdc /dev/sdd
Un target de failover (4 grupos de prioridad, cada uno con un dispositivo de multipath):
0 2147483648 multipath 4 round-robin 1 0 /dev/sda round-robin 1 0 /dev/sdb
round-robin 1 0 /dev/sdc round-robin 1 0 /dev/sdd
Repartir la E/S (multibus) a un único grupo de prioridad:
0 2147483648 multipath 1 round-robin 4 0 /dev/sda /dev/sdb /dev/sdc /dev/sdd
5.3.2 PASOS PARA CREAR UN ALMACENAMIENTO FC MULTIPATH

A continuación se detallan los pasos a seguir para crear un almacenamiento multicamino.
• Instalar el RPM device-mapper-multipath
• Configurar el fichero /etc/multipath.conf
• Cargar los módulos: modprobe dm_multipath ; modprobe dm-round-robin
• Activar el servicio: chkconfig multipathd on
• Arrancar el servicio: service multipathd start
• Comprobar que funciona: multipath -l
Los dispositivos SCSI disponibles se pueden ver en /proc/scsi/scsi:

# cat /proc/scsi/scsi
Attached devices:
Host: scsi0 Channel: 00 Id: 00 Lun: 00
Vendor: SEAGATE Model: ST318305LC Rev: 2203
Type: Direct-Access ANSI SCSI
revision: 03
Vendor: ATA Model: ST340014AS Rev: 8.05
revision: 05
Vendor: IET Model: VIRTUAL-DISK Rev: 0
revision: 04
Si es necesario rehacer un escaneo SCSI, se puede ejecutar el comando:

echo "- - -" > /sys/class/scsi_host/host0/scan
Donde host0 se reemplaza por la HBA que se desea usar. También se puede hacer un
redescubrimiento fabric:
echo “1” > /sys/class/fc_host/host0/issue_lip
echo "- - -" > /sys/class/scsi_host/host0/scan
Lo que envía un LIP (primitiva de iniciación de loop) al fabric. En el inicio, el acceso al HBA puede ser
lento o experimentar timeouts.
5.3.3 Configuración y consultas Multipath

Las secciones del fichero /etc/multipath.conf son:

• defaults: Configuración por defecto para herramientas multipath.
• blacklist: List de nombres de dispositivo específicos que no se consideren para multipath.
• blacklist_exceptions: Lista de candidatos para multipath que de otra manera se colocarían en la
blacklist.
• multipaths: Lista de características de configuración multipath.
• devices: Lista de configuraciones de controladores de almacenamiento.
Ejemplo:
blacklist {
wwid 26353900f02796769
devnode "^(ram|raw|loop|fd|md|dm-|sr|scd|st)[0-9]*"
devnode "^hd[a-z]"
devnode "^cciss!c[0-9]d[0-9]*"
}
Ejemplo:
multipaths {
multipath {
wwid 3600508b4000156d700012000000b0000
alias yellow
path_grouping_policy multibus
path_checker readsector0
path_selector "round-robin 0"
failback manual
rr_weight priorities
no_path_retry 5
}
multipath {
wwid 1DEC_____321816758474
alias red
}
}
Para hacer preguntas usamos multipath -l
• multipath [-l | -ll | -v[0|1|2]]
• dmsetup ls --target multipath, para determinar qué números largos son necesarios para las
entradas del device mapper.
• dmsetup table
Ejemplo:
# multipath -l
mpath1 (3600d0230003228bc000339414edb8101)
[size=10 GB][features="0"][hwhandler="0"]
\_ round-robin 0 [prio=1][active]
\_ 2:0:0:6 sdb 8:16 [active][ready]
\_ round-robin 0 [prio=1][enabled]
\_ 3:0:0:6 sdc 8:64 [active][ready]
Para cada dispositivo multipath, las 2 primeras líneas de esta salida se interpretan de la siguiente
manera:
acción_si_alguno:alias (WWID_if_different_from_alias)
[size][features][hardware_handler]

Ejercicios:
1.Configurar multipath usando el dispositivo iSCSI SAN (en el nodo1)
[root@node1 ~]# vi /etc/iscsi/iscsid.conf
node.session.timeo.replacement_timeout = 10
node.session.err_timeo.lu_reset_timeout = 10
[root@node1 ~]# service iscsid restart
Cambiamos la configuración de los targets exportados (host) para que se puedan ver por la 2ª IP.
[root@station9 ~]# vi /etc/tgt/targets.conf
</target>
[root@station9 ~]# service tgtd restart
Descubrir targets en el primer interfaz en el nodo:
[root@node1 ~]# service iscsi start
[root@node1 ~]# chkconfig iscsi on
172.17.109.254 -l
portal: 172.17.109.254,3260]
172.17.109.254,3260]: successful
Ver que se han creado discos para estos targets:

Descubrir targets en el segundo interfaz en el nodo:
172.17.209.254 -l
portal: 172.17.209.254,3260]
172.17.209.254,3260]: successful
Ver que se han creado discos para estos targets:
Disk /dev/sdb: 5368 MB, 5368709120 bytes

/dev/sdb1 1 191 982855 fd Linux raid autodetect
Podemos comprobar que son el mismo disco, en realidad:
[root@node1 ~]# /sbin/scsi_id -g -u -s /block/sda
S_beaf11
[root@node1 ~]# /sbin/scsi_id -g -u -s /block/sdb
S_beaf11
[root@node1 ~]# yum -y install device-mapper-multipath
Me aseguro que mis dispositivos no están en la blacklist
[root@node1 ~]# vi /etc/multipath.conf
defaults {
udev_dir /dev
polling_interval 10
selector "round-robin 0"
path_grouping_policy failover
getuid_callout "/sbin/scsi_id -g -u -s /block/%n"
prio_callout /bin/true
path_checker readsector0
rr_min_io 100
max_fds 8192
rr_weight priorities
failback immediate
no_path_retry fail
user_friendly_names yes
}
blacklist {
wwid 26353900f02796769
devnode "^(ram|raw|loop|fd|md|dm-|sr|scd|st)[0-9]*"
devnode "^hd[a-z]"
}
[root@node1 ~]# modprobe dm_multipath
[root@node1 ~]# modprobe dm_round_robin
[root@node1 ~]# lsmod |grep dm_
dm_round_robin 7617 0
dm_multipath 24909 1 dm_round_robin
scsi_dh 11713 1 dm_multipath
dm_raid45 67273 0
dm_message 6977 1 dm_raid45
dm_region_hash 15809 1 dm_raid45
dm_mem_cache 9921 1 dm_raid45
dm_snapshot 23013 0
dm_zero 6209 0
dm_mirror 24521 0
dm_log 14657 3 dm_raid45,dm_region_hash,dm_mirror
dm_mod 63225 9
dm_multipath,dm_raid45,dm_snapshot,dm_zero,dm_mirror,dm_log
Iniciamos el servicio y hacemos que los cambios sean persistentes
[root@node1 ~]# chkconfig multipathd on
[root@node1 ~]# service multipathd start
Vemos los cambios
/dev/dm-1p1 1 191 982855 fd Linux raid autodetect

[root@node1 ~]# multipath -ll
mpath0 (S_beaf11) dm-1 IET,VIRTUAL-DISK
[size=5.0G][features=0][hwhandler=0][rw]
\_ 0:0:0:1 sda 8:0 [active][ready]
Probamos los dispositivos para asegurarnos que sobreviven a un failover
He de crear un FS porque por mi multicamino estoy accediendo a un dispositivo de bloques RAW
(estamos usando una SAN, con una NAS no haría falta, pues las operaciones se hacen sobre FS). Como
el disco en la SAN está particionado, he de añadir p1 (primera partición) al multicamino mpath0.
[root@node1 ~]# mke2fs -j /dev/mapper/mpath0p1
[root@node1 ~]# mkdir /mnt/data
[root@node1 ~]# mount /dev/mapper/mpath0p1 /mnt/data/
[root@node1 ~]# cp /etc/passwd /mnt/data/
[root@node1 ~]# ifdown eth3
[root@node1 ~]# cat /mnt/data/passwd
root:x:0:0:root:/root:/bin/bash
bin:x:1:1:bin:/bin:/sbin/nologin
daemon:x:2:2:daemon:/sbin:/sbin/nologin
adm:x:3:4:adm:/var/adm:/sbin/nologin
[...]
[root@node1 ~]# echo "HELLO" >> /mnt/data/hola
[root@node1 ~]# cat /mnt/data/hola
HELLO
sdb: checker msg is "readsector0 checker reports path is down"
\_ 1:0:0:1 sdb 8:16 [failed][faulty]
[root@node1 ~]# ifup eth3
6.- CLUSTERING
El término cluster se aplica a los conjuntos o agrupaciones de computadoras construidos mediante

la utilización de componentes de hardware comunes y que se comportan como si fuesen una única
computadora.

Los clusters son usualmente empleados para mejorar el rendimiento y/o la disponibilidad por encima
de la que es provista por un solo computador típicamente siendo más económico que computadores
individuales de rapidez y disponibilidad comparables.
De un cluster se espera que presente combinaciones de los siguientes servicios:
1. Alto rendimiento
2. Alta disponibilidad
3. Balanceo de carga
4. Escalabilidad
El cluster puede estar conformado por nodos dedicados o por nodos no dedicados.
En un cluster con nodos dedicados, los nodos no disponen de teclado, ratón ni monitor y su uso está
exclusivamente dedicado a realizar tareas relacionadas con el cluster. Mientras que, en un cluster con
nodos no dedicados, los nodos disponen de teclado, ratón y monitor y su uso no está exclusivamente
dedicado a realizar tareas relacionadas con el cluster, el cluster hace uso de los ciclos de reloj que el
usuario del computador no está utilizando para realizar sus tareas.
6.1. Red Hat Cluster Suite Introduction
Red Hat Cluster Suite (RHCS) es un conjunto integrado de componentes de software que puede ser
implementado en una amplia variedad de configuraciones para cubrir las necesidad de rendimiento,
alta disponibilidad, balance de carga, escalabilidad, compartición de archivos y economía de recursos.
La infraestructura de cluster Red Hat Cluster Suite proporciona las funciones básicas para que un
grupo de computadores (llamados nodos o miembros) trabajen juntos en un cluster. Una vez el cluster
ha sido formado con la infraestructura de cluster, se pueden utilizar otros componentes de Red Hat
Cluster Suite para cubrir las necesidades del cluster (por ejemplo, se puede establecer un cluster para
compartir archivos en un sistema de archivo GFS o establecer un servicio con recuperación contra
fallos). La infraestructura de cluster lleva a cabo las siguientes funciones:
● Administración de cluster
● Administración de los cierres de exclusión
● Fencing
● Administración de la configuración de cluster
Conga provee un agente que es residente en los servidores de producción y es gestionado a través de
un interfaz web, pero la GUI está en cada una de las máquinas donde se desee ejecutar.
luci y ricci interactuan de la siguiente manera:

luci es un servidor web que sirve como consola central para gestionar uno o más clusters y no puede
ejecutrase en uno de los nodos del cluster. De manera ideal, luci sera una máquina con entorno
gráfico y capacidades de red que se pueda conectar a los nodos; mantiene una base de datos de
ususarios y nodos.
ricci es un agente que se instala en todos los servidores que han de ser gestionados.
El cliente web se loga de manera segura (mediante SSL) en el servidor luci, a través del interfaz web,
luci envía comandos a los agentes ricci que están en los nodos a gestionar.
6.2. CLUSTER MANAGER CMAN.
El único fichero de configuración del cluster es el /etc/cluster/cluster.conf.
CMAN mantiene rastro de las membresías sondeando los mensajes de otros nodos del cluster.
Cuando las membresías del cluster cambian, el administrador de cluster notifica a los otros
componentes de la infraestructura para que lleven a cabo las acciones apropiadas. Por ejemplo,
cuando el nodo A entra a un cluster y monta el sistema de archivos GFS que los nodos B y C ya tienen
montado, se necesita de un nuevo diario y una nueva administración de cierres de exclusión para que
el nodo A utilice este sistema de archivos. Si un nodo del cluster no transmite un mensaje durante un
tiempo determinado, el administrador del cluster remueve el nodo del cluster y comunica a los otros
componentes de la infraestructura de cluster que el nodo no es ya miembro del cluster.

6.3. FENCING
Fencing es la desconexión de un nodo del cluster del almacenamiento compartido. Mediante fencing,
se corta la E/S de dicho almacenamiento compartido, asegurando así la integridad de los datos. La
infraestructura de cluster realiza fencing a través del demonio fenced.
Cuando CMAN determina que un nodo ha fallado, CMAN comunica a los otros componentes de la
infraestructura de cluster que el nodo ha fallado. fenced ejecuta una acción de aislamiento sobre el
nodo fallido cuando la comunicación es recibida. Otros componentes de la infraestructura de cluster
determinan que acciones se deben tomar. Tras recibir la confirmación de que el nodo ha sido aislado,
se ejecutan las tareas de recuperación. se liberan los cierres del nodo fallido.
Hay dos tipos de fencing:

• Power fencing
También conocido como STONITH ("Shoot The Other Node In The
Head"), es una analogía para parar rápida y completamente un nodo errante.
• Fabric fencing
Fibre Channel switch o reservas SCSI. Al hacer reservas SCSI lo que hago es decirle a ciertas
máquinas que pueden o no acceder al almacenamiento SCSI.
/etc/init.d/scsi_reserve
/sbin/fence_scsi
fence_scsi_test -s: para saber cuales de mis dispositivos scsi soportan scsi_fencing
Todas las máquinas han de ser capaces se hacer fencing del resto de nodos del dominio de fencing.
Los sitemas de E/S de fencing tienen 2 componentes:

• Demonio de fencing: recibe las peticiones de fencing como eventos de servicios de cman.
Determina cómo hacer fencing de un nodo en fallo buscando en la información de CCS.
• Agente de fencing: es un interfaz a un hardware específico.

fence_tool join sirve para unirse a un dominio de fencing
fence_tool leave sirve para quitarse de un dominio de fencing (no del cluster)
El comando fence_node obtiene toda la información necesaria para CCS para la E/S de un nodo de
fencing concreto y entonces ejecuta la acción de fencing haciendo una llamada al agente adecuado
(cuando hacemos fencing, siempre queremos apagar la máquina de forma brusca, no ordenada).
Hay muchos tipos de dispositivos de agentes de fencing CCS, se configuran en cluster.conf:

<fencedevices>
<fencedevice agent="fence_apc" ipaddr="172.16.36.107" login="nps"
name="apc" passwd="password"/>
</fencedevices>
6.3.1. CONFIGURACIÓN DE UN DOMINIO DE FAILOVER
Un dominio de failover es un subconjunto de nodos de cluster que son susceptibles de ejecutar un

servicio de cluster cuando se produzca un fallo de un nodo. Sus características son (siempre que se
configure en modo ‘ordered’):
● Unrestricted: Permite especificar un subconjunto de miembros preferidos, pero el servicio
podrá correr en cualquiera de ellos.
● Restricted: Permite restringir los miembros que ejecutarán un servicio particular del cluster, si
no hay miembros disponibles, el servicio no se ejecutará.
● Unordered: El servicio se ejecutará en un nodo sin priorizar u ordenar.
● Ordered: Permite especificar un orden de preferencia para ejecutar servicios en nodos.
● Failback: Permite especificar si un servicio en el dominio de failover debe devolver el control
del servicio una vez que el nodo en el que corría antes del fallo esté operativo otra vez.
Por defecto, los dominios de failover son unrestricted y unordered.
Se pueden configurar los dominios de failover desde el interfaz de luci en la parte de arriba de la
sección “cluster display” en “Failover Domains”.
6.4. QUORUM
El quórum se determina a través de la comunicación de mensajes entre los nodos del cluster a través
de Ethernet. Opcionalmente, se puede determinar el quórum a través de la combinación de mensajes
comunicados a través de Ethernet y a través de un disco de quórum. Para el quórum a través de
Ethernet, el quórum consiste del 50% de los votos más uno. Para el quórum a través del disco de
quórum, el quórum depende de las condiciones especificadas por el usuario.
NOTA: Por defecto, cada nodo tiene un voto. Sin embargo, se puede modificar la configuración para
que cada nodo tenga más de un voto.
cman puede sufrir una situación de “cerebro-dividido” ("split-brain") es decir, 2 grupos de nodos han
sido divididos podrían tomar su nombre del mismo grupo. Si ambos clusters accedieran al mismo
almacenamiento compartido, los datos se corromperían. Por tanto, cman debe garantizar (usando
un esquema de votos de mayoría de quorum) que sólo uno de los dos clusters divididos se mantiene

activo. Para ello, cman hace frente de manera segura a escenarios de “cerebro dividido” haciendo que
cada nodo envíe un broadcast o multicast con un latido (heartbeat) de red que indica a los miembros
de clúster que se encuentra on-line además de escuchar los mensajes que pueden venir de los otros
nodos.
Cada nodo construye su propia visión de qué nodos cree que están on-line. Cuando se detecte que
un nodo se ha vuelto on-line u off-line, se dice que ocurre una transición de miembros. La transición
de miembros disparan la elección en la que un nodo propone una vista y todos los otros nodos
informe si el punto de vista propuesto coincide con su punto de vista interno. El grupo de gerente de
entonces hacerse una idea de qué nodos están en línea y cuenta sus respectivos votos del quórum. Si
exactamente la mitad o más de los votos espera desaparecen, el quórum ya no existe (salvo en los dos
nodos caso especial). Sólo los nodos que han quórum puede ejecutar un servicio de clúster virtual.
6.5. COMANDOS DE ADMINISTRACIÓN
Los valores de votación descritos arriba se pueden ver con el comando cman_tool status.
[root@node1 cluster]# cman_tool status
Version: 6.2.0
Config Version: 7
Cluster Name: cluster9
Cluster Id: 26785
Cluster Member: Yes
Cluster Generation: 8
Membership state: Cluster-Member
Nodes: 2
Expected votes: 1
Total votes: 2
Quorum: 1
Active subsystems: 9
Flags: 2node Dirty
Ports Bound: 0 11 177
Node name: node1.cluster9.example.com
Node ID: 2
Multicast addresses: 239.192.104.10
Node addresses: 172.17.9.1
Según se vayan añadiendo nodos al cluster, el número total de votos aumenta dinámicamente. El total
de votos nunca decrece dinámicamente; si hay quorum, un código de salida 0 ha de ser devuelto por
el comando clustat -Q (quien no produce salida alguna):
# clustat -Q
# echo $?
0
Para poder obtener el quorum, se necesitan = (expected_votes / 2) + 1 (la mitad más 1).
En un ejemplo de un cluster de 10 nodos:
2 nodes @ 10 votes each = 20 votes
8 nodes @ 1 vote each = 8 votes
----------------------------------

Needed for Quorum = 15 votes
Para tomar el control de un servicio tras un fallo, es necesario obtener el quorum y hacer fencing, si
no se consigue hacer fencing, no se puede continuar arrancando / parando servicios, la actividad del
cluster se bloquea.
Podemos ver y cambiar los votos con cman_tool expected -e <votos> y para ver información podemos
usar cman_tool status y ccs_tool lsnode
Para ver cuántos votos tiene cada nodo del cluster:

# ccs_tool lsnode
Cluster name: test1, config_version: 19
Nodename Votes Nodeid Fencetype
node2.cluster-1.example.com 1 1 apc1
Para modificar los votos actualmente asignados a un nodo:

# cman_tool votes -v <votes>
Para unirnos a un cluster:

# cman_tool join
Para dejar un cluster (esto fallará si hay sistemas aún usando el cluster):
# cman_tool leave
Para ver el estado del cluster local:

# cman_tool status
Para ver los miembros del cluster local:

# cman_tool nodes
En el caso especial de un cluster de dos nodos, queremos preservar el quorum cuando uno de los dos
nodos falla; para ello, el cluster de dos nodos son una excepción a la decisión de quorum “normal” de
tal manera que para que un nodo siga operando cuando el otro está en fallo, el cluster entra en un
modo especial llamado modo “two_node”. Para poder operar en modo “two_node” hay que poner en
la sección de configuración de cman los valores two_node y expected_votes values a 1:
<cman two_node="1" expected_votes="1"></cman>
Cuando la configuración del cluster se modifica (en uno de los nodos) de manera manual en el fichero
/etc/cluster/cluster.conf hay que asegurarse de que el resto del cluster se entere, para ello está el
comando ccs_tool. Los pasos a seguir son:
1. Editar el fichero /etc/cluster/cluster.conf
2. Informar al Cluster Configuration System (CCS) y Cluster Manager (cman) del cambio y propagarlo al
resto de los nodos:
# ccs_tool update /etc/cluster/cluster.conf
Config file updated from version 2 to 3
Update complete.
3. Verificar que la información de CMAN y los cambios al fichero cluster.conf se han propagado al
resto de los nodos con alguno de los comandos:

# cman_tool status | grep "Config version"
Config Version: 3
# cman_tool version
6.0.1 config 3
El número entero ha de ser incrementado a mano cada vez que se realizan cambios al fichero de
configuración.
clusvcadm es la herramienta de administración del Cluster. Hay una sutil diferencia entre un servicio
parado (stopped) y deshabilitado (disabled). Cuando un servicio está parado, la transición de nodo
provoca que el servicio se vuelva a arrancar. Cuando el servicio está deshabilitado, el servicio se
mantiene deshabilitado aunque se haya realizado la transición a cualquier otro nodo del cluster.
clusvcadm -d <group>: Deshabilita un grupo

clusvcadm -e <group>: Deshabilita un grupo
clusvcadm -s <group>: Para un grupo
Un servicio puede ser reubicado manualmente en cualquier otro nodo del cluster usando clusvcadm
siempre que en la máquina en la que lo ejecutemos, esté corriendo todos los demonios del cluster y
sea la que tenga el quorum:
# clusvcadm -r webby -m node1.example.com
Ejercicio:
1. Configuración de cluster
[root@node1 ~]# yum grouplist | grep -i cluster
This system is not registered with RHN.
RHN support will be disabled.
Cluster Storage
Clustering
[root@node1 ~]# yum groupinstall Clustering
[root@node2 ~]# yum groupinstall Clustering
[root@station9 ~]# chkconfig luci on
[root@station9 ~]# service luci start
[root@station9 ~]# luci_admin init
Initializing the luci server
Creating the 'admin' user
Ahora nos conectamos a la URL https://station9.example.com:8084 para poder gestionar el cluster

Desde la web, creamos un cluster, pero antes hay que arrancar ricci en los nodos a los que nos vamos
a conectar.
[root@node1 ~]# chkconfig ricci on

[root@node1 ~]# service ricci start

Creamos los nodos declusterrrs node1 y node2
[root@node1 ~]# more /etc/hosts
172.17.9.1 node1.cluster9.example.com node1
Cada nodo del cluster ha de tener un mecanismo de fencing.

Para hacer fencing en Linux de VMs hay que tener corriendo el demonio fence_xvmd, cosa que
podemos conseguir arrancandolo a mano:
[root@station9 ~]# fence_xvmd -L -I cluster -f -d
O bien con un cluster pequeñito que lo tenga como componente:
Hay que asegurarse que el fichero /etc/cluster/fence_xvm.key, existe en todos los nodos virtuales

y en la máquina física. Se puede generar a mano o con el interface de luci:
Ahora deberían estar los ficheros en todas las máquinas:

[root@station9 ~]# cd /etc/cluster/
[root@station9 cluster]# ls
cluster.conf fence_xvm.key
[root@node1 ~]# cd /etc/cluster/
[root@node1 cluster]# ls
[root@node2 ~]# cd /etc/cluster/
[root@node2 cluster]# ls
Creamos un servicio en el cluster y lo configuramos.

2. Configurar el nodo 3 para que se añada al cluster mediante línea de comandos.
[root@node3 ~]# yum -y install ricci httpd
Comprobar que el iniciador del nodo3 está configurado y que la tabla de particiones es consistente
con el nodo1 y nodo2
[root@node3 ~]# /root/RH436/HelpfulFiles/setup-initiator -b1
[root@node3 ~]# partprobe /dev/sda
Una vez añadido el nodo usando luci, copiarle el fichero de claves de fencing para VMs
[root@node1 cluster]# scp /etc/cluster/fence_xvm.key node3:/etc/cluster/fence_xvm.key
Cambiar el servicio webby al nodo 3 (luci) y comprobarlo en linea de comandos
[root@node2 cluster]# clustat -i 1
Cluster Status for cluster9 @ Wed Dec 1 14:56:59 2010
Member Status: Quorate
Member Name ID Status

------ ---- ---- ------
node2.cluster9.example.com 1 Online, rgmanager
node3.cluster9.example.com 3 Online, Local, rgmanager
Service Name Owner (Last)

State
------- ---- ----- ------
-----
service:webby (node2.cluster9.example.com)
failed
[...]

State
------- ---- ----- ------
-----
service:webby node3.cluster9.example.com
started
También se puede hacer desde cualquier nodo con el comando:
[root@node2 cluster]# clusvcadm -r webby -m node3.cluster9.example.com
Trying to relocate service:webby to node3.cluster9.example.com...Success
service:webby is now running on node3.cluster9.example.com
Vemos el estado actual de los votos
[root@node2 cluster]# cman_tool status
Nodes: 3
Expected votes: 3
Total votes: 3
Quorum: 2
Paramos uno de los nodos para ver cómo obtiene quorum el cluster
[root@node3 ~]# poweroff -f
State
------- ---- ----- ------
-----
service:webby node1.cluster9.example.com
started
Al parar el nodo 2, el cluster se para también
Message from syslogd@ at Wed Dec 1 15:31:33 2010 ...
node1 clurgmgrd[9098]: <emerg> #1: Quorum Dissolved
7.- DISCO DE QUORUM
No es el mecanismo principal del cálculo de quorum en un cluster RH, sin embargo nos ayudará a
solucionar los problemas de un cluster de 2 nodos y el que se produce cuando sólo nos queda un
nodo en el cluster pero aún así deseo seguir dando servicio.
Un disco de quorum permite la configuración de heurísticas independientes del cluster que cada nodo
del cluster puede determinar usar para decidir si es apto o no para formar parte de dicho cluster;
especialmente para manejar particiones de redes ("split-brain") o cuando la mayoría de los nodos
del cluster fallan. El disco de quorum confiene información sobre el estado y un 'timestamp'. La
información válida se comunica a los otros nodos del cluster usando un "disco de quorum" que reside
en el almacenamiento compartido. El demonio del disco de quorum requiere que se pueda acceder
a un dispositivo de bloques compartido con acceso concurrente de lectura / escritura para todos los
nodos del cluster. El dispositivo de bloques compartido puede ser un array multi-puerto SCSI RAID, un
RAID SAN Fiber-Channel, un target iSCSI RAID, o incluso, GNBD.
Aparece como un nodo más, sin embargo no lo es. Básicamente es un conjunto de demonios de
quórum basados en disco para Cluster de Linux / CMAN. Se comunican entre ellos a través de la
red para decidir quién es el disco de quorum, almacenando la información en un disco compartido.
Los discos de quorum disponibles, ofrecen un voto más al cluster. Una ventaja inmediata, es que el

quorum sólo recaerá en aquellos nodos que puedan acceder a la red de almacenamiento, por tanto,
nos permite identificar clara y rápidamente los nodos con problemas. Un disco de quorum no se
considera siempre disponible, sino que deciden dicha disponibilidad en función de una serie de reglas
(por ejemplo, poder hacer un ping a la red privada del cluster).
El disco de quorum se comunica con cman, ccsd (el demoino Cluster Configuration System) y con el
almacenamiento compartido. Se comunica con cman para anunciar la disponibilidad del dispositivo
de quorum, y se comunica con ccsd para obtener información de la configuración. Por último, se
comunica con el almacenamiento compartido para comprobar y guardar sus estados.
Las escrituras en disco se hacen a bajo nivel, no con un FS o un disco montado.
Los disco de quorum están limitados a 16 nodos por cluster. El ID del nodo ha de ser configurado
estáticamente en el /etc/cluster/cluster.conf, secuencialmente del 1 al 16. El servicio cman ha de estar
corriendo antes de poder iniciar el disco de quorum.
Cada cierto intervalo de segundos ('interval'), los nodos escriben cierta información básica en
su bloque individual de estado en su disco de quorum, esta información (timestamp, estado,
disponibilidad) se inspecciona por los otros nodos para determinar si el nodo está colgado o si ha
perdido acceso al almacenamiento compartido. Si un nodo falla al actualizar su estado durante 'tko'
veces, se declara offline y no cuenta para el cálculo de votos de quorum. Si un nodo empieza a
escribir otra vez en el disco de quorum, se vuelve a declarar online después de tko_up veces que haya
actualizado su estado (por defecto tko/3).
El tiempo de espera de desalojo de CMAN (post_fail_delay) debe ser 2 veces el del demonio de
quórum:
Ejemplo de la etiqueta del bloque del quorumd, en etc/cluster/cluster.conf:

<quorumd interval="1" tko="10" votes="1" label="testing">
7.1. HEURÍSTICAS
Una heurística es una prueba arbitraria ejecutada para ayudarnos a determinar un resultado. El
mecanismo del disco de quorum usa heurísticas para ayudar a determinar si un nodo es válido para
formar parte de un cluster, además del mecanismo de heartbeat que ya provee el cluster. Puede
comprobar acceso a redes o disponibilidad del almacenamiento compartido. El administrador puede
configurar hasta 10 (del 1 al 10) heurísticas puramente arbitrarias. Los nodos de puntuación de más
de 1/2 de los puntos totales que ofrecen todas las heurísticas (o min_score si se define así) son válidos
para reclamar los votos que ofrece el demonio de quórum en los cálculos del quórum del clúster. Las
heurísticas pueden ser cualquier comando ejecutable mediante 'sh -c <string>', como por ejemplo:
<heuristic program="[ -f /quorum ]" score="1" interval="2"/>
Este comando de shell comprueba la existencia de un fichero llamado "/quorum", sin él, el nodo dirá
que no está disponible,
Ejemplo:
<heuristic program="ping A -c1 -t1" score="1" interval="2" tko="3"/>

</quorumd>
7.2. Configuración del disco de quorum
Desde RHEL4U4 el disco de quorum se puede configurar manualmente en /etc/cluster/

cluster.conf o bien usando la herramienta gráfica system-config-clsuster (sólo en el momento
de creación del cluster) o mediante Conga. Si el disco de quorum está en un volumen lógico, qdiskd
no puede arrancar hasta que clvmd esté corriendo. Un problema potencial es que clvmd no puede
arrancar hasta que el cluster haya establecido el quorum, y el quorum no puede establecearse sin
qdiskd. Como workaround sugerido, es no poner los votos esperados del cluster hasta que el cluster
haya arrancado. Poner todos los nodos online e iniciar el demonio qdiskd sólo después de que el
clúster se esté ejecutando. Esto permite que los votos aumenten de forma normal.
Para arrancar qdiskd:

# service qdiskd start
# chkconfig qdiskd on
Para crear un qdiks se usa la herramienta "Cluster Quorum Disk" (mkqdisk), que se usa tanto para
crear como para ver los distintos disco de quorum accesibles desde un determinado nodo del cluser.
Crear un disco de quorum

# mkqdisk -c <device> -l label
Listar todos los disco de quorum
# mkqdisk -L
Obtener información de un disco de quorum determinado
# mkqdisk -d -f label
**IMPORTANTE** El dispositivo ha de ser un dispositivo de bloques raw, sin montar y sin formato.
También debería ser pequeño, pues el disco de quorum sólo va a usar 72 bloques.
Ejemplo: Cluster de 2 nodos y un disco de Quorum Disk Tiebreaker

<cman two_node="0" expected_votes="3" .../>
<clusternodes>
<clusternode name="node1" votes="1" ... />
</clusternodes>
<heuristic program="ping -c1 -t1 hostA" score="1" interval="2" tko="3"/>
</quorumd>
1) En el bloque <cman> el flag sin definir two_node (o con valor 0) de tal manera que un único voto no
es suficiente para mantener el quorum.
2) También en el bloque <cman>, definir expected_votes a 3, para que sea neceario un mínimo de 2
votos para mantener el quorum.
3) Definir el parámetro votos del nodo a 1 y cuenta de votos del disco de quorum a 1, así se requieren
2 votos de quórum; un único nodo superviviente debe cumplir con el requisito de la heurística (ser
capaz de hacer un ping -c1 -t1 hostA, en este) para ganar el voto extra ofrecido por el demonio del
disco de quorum y mantener el cluster funcionando.

Ejemplo: Mantener el Quorum cuando han fallado todos los nodos menos uno
<cman expected_votes="6" .../>
<clusternodes>
</clusternodes>
<heuristic program="ping A -c1 -t1" score="1" interval="2" tko="3"/>
<heuristic program="ping B -c1 -t1" score="1" interval="2" tko="3"/>
<heuristic program="ping C -c1 -t1" score="1" interval="2" tko="3"/>
</quorumd>
En este ejemplo, 'expected_votes' se han incrementado a 6, en vez de el valor normal de 3, por tanto
se requieren 4 votos para determinar quorum. Un disco de quorum se configura de tal manera que
contribuya con 3 votos (<quorumd votes="3" ... >) al cluster si tiene más de la mitad de la puntuación
total posible para la prueba heurística, y sigue siendo de escritura. El disco de quórum tiene tres
pruebas heurísticas definidas, cada una de ellas está configurada para anotar un punto (<heuristic
Program="ping Un -c1 score="1" -t1" ...>) si se puede hacer ping a un router diferente (A, B, o C),
para un total de 3 puntos posibles. Para obtener 2 de los 3 puntos necesarios para pasar las pruebas
heurísticas, por lo menos dos de los tres routers deben estar funcionando. Si es así, y sigue siendo
el disco de quórum de escritura, tenemos todos los 3 de los votos de quorumd. Si, en cambio, no
hay routers o solamente un router está funcionando, no se suman puntos suficientes para aprobar
y no obtiene los votos del disco de quórum. Del mismo modo, si no se puede escribir en el disco de
quórum, no se reciben votos del disco de quórum sin importar cuántas heurísticas haya pasado.
Como resultado, aunque sólo haya un nodo funcional, el clúster puede permanecer en quorum
siempre que el nodo restante puede hacer ping a dos de los tres routers (que ganan un punto de
aprobación) y se pueda escribir en el disco de quorum, quien gana los 3 votos extra que necesita para
el quórum. El <quorumd> y los parámetros del bloque de <heuristic> tko establecen el número de
intentos fallidos antes de que se
considere en fallo, y el intervalo define la frecuencia (en segundos) de lectura / escritura de los
intentos del disco de quorum y en qué heurística se ha votado, respectivamente.
Ejercicios:
1. Después de quitar el nodo3 del cluster (para obtener un cluster de 2 nodos), comprobamos el
estado:
[root@c9n1 ~]# cman_tool status
Version: 6.2.0
Config Version: 18
Cluster Name: cluster9
Cluster Id: 26785
Cluster Member: Yes
Cluster Generation: 124
Membership state: Cluster-Member
Nodes: 2
Expected votes: 1
Total votes: 2
Quorum: 2

Active subsystems: 9
Flags: 2node Dirty
Ports Bound: 0 11 177
Node name: node1.cluster9.example.com
Node ID: 2
Multicast addresses: 239.192.104.10
Node addresses: 172.17.9.1
Create a new 10MB quorum partition named /dev/sdaN and assign it the label myqdisk.
[root@c9n1 ~]# fdisk /dev/sda
/dev/sda3 383 385 15438 83 Linux
[root@c9n1 ~]# partprobe
[root@c9n1 ~]# mkqdisk -c /dev/sda3 -l mydisk
mkqdisk v0.6.0
Writing new quorum disk label 'mydisk' to /dev/sda3.
WARNING: About to destroy all data on /dev/sda3; proceed [N/y] ? y
Initializing status block for node 1...
Verify the quorum partition was made correctly:
[root@c9n1 ~]# mkqdisk -L
mkqdisk v0.6.0 <<<< No vemos nada, porque tenemos mpath corriendo, y al intentar acceder al /
dev/sda estoy intentando acceder al camino, mkqdisk se da cuenta y no lo hace.
[root@c9n1 ~]# fdisk -l
[...]
Disk /dev/dm-1: 5368 MB, 5368709120 bytes

/dev/dm-1p3 383 385 15438 83 Linux
Vemos los dispositios de multipath
[root@c9n1 ~]# multipath -l
\_ 1:0:0:1 sda 8:0 [active][undef]
\_ 0:0:0:1 sdb 8:16 [active][undef]

Le decimos al sistema que descubra el otro camino existente
[root@c9n1 ~]# partprobe /dev/sdb
Ahora comprobamos que el sistema ve todos mis dispositivos
[root@c9n1 ~]# cat /proc/partitions
major minor #blocks name
3 0 8388608 hda
3 1 104391 hda1
3 2 2096482 hda2
3 3 522112 hda3
3 4 987997 hda4
253 0 2064384 dm-0
8 0 5242880 sda
8 1 982855 sda1
8 2 982886 sda2
8 3 15438 sda3
8 16 5242880 sdb
8 17 982855 sdb1
8 18 982886 sdb2
8 19 15438 sdb3
253 1 5242880 dm-1
253 2 982855 dm-2
253 3 982886 dm-3
Aún no vemos el 3 dispositivo de multipath (al camino recién creado en /dev/sda3)
[root@c9n1 ~]# ls /dev/mpath/
mpath0 mpath0p1 mpath0p2
Borramos todos los dispositivos de multipath que no estén en uso
[root@c9n1 ~]# multipath -F
Volvemos a descubrir todos los dispositivos de multipath existentes
[root@c9n1 ~]# multipath
create: mpath0 (S_beaf11) IET,VIRTUAL-DISK
[size=5.0G][features=0][hwhandler=0][n/a]
\_ round-robin 0 [prio=0][undef]
\_ 1:0:0:1 sda 8:0 [undef][ready]
\_ 0:0:0:1 sdb 8:16 [undef][ready]
\_ 1:0:0:1 sda 8:0 [active][undef]
\_ 0:0:0:1 sdb 8:16 [active][undef]
[root@c9n1 ~]# ls /dev/mpath/
mpath0 mpath0p1 mpath0p2 mpath0p3
Ahora mkqdisk sí ve mi nuevo camino, a través del dispositivo de multipath correspondiente
mkqdisk v0.6.0
/dev/dm-4:
/dev/mapper/mpath0p3:
/dev/mpath/mpath0p3:
Magic: eb7a62c2
Label: mydisk

Created: Thu Dec 2 11:14:19 2010
Host: c9n1.example.com
Kernel Sector Size: 512
Configurar el cluster con la interfaz luci:
Interval: 2
Votes: 1
TKO: 10
Minimum Score: 1
Device: /dev/sdaN
Label: myqdisk
Heuristics
Path to Program: ping -c1 -t1 172.17.X.254
Interval: 2
Score: 1
Poner expected_votes="3" y two_node="0" e incrementar config_version

[root@c9n1 ~]# vi /etc/cluster/cluster.conf
<cman expected_votes="3" two_node="0"/>
<cluster alias="cluster9" config_version="20" name="cluster9">
Actualizar el cluster
[root@c9n1 ~]# ccs_tool update /etc/cluster/cluster.conf

Config file updated from version 19 to 20
Update complete.
Start qdiskd on both nodes and make sure the service starts across reboots.
[root@c9n1 ~]# service qdiskd start
[root@c9n1 ~]# chkconfig qdiskd on
En el otro nodo falla, porque no hemos descubierto el multipath, y por tanto no ve los caminos
mkqdisk v0.6.0
Disk /dev/hda: 8589 MB, 8589934592 bytes
/dev/hda1 * 1 13 104391 83 Linux
/dev/hda2 14 274 2096482+ 8e Linux LVM
/dev/hda3 275 339 522112+ 82 Linux swap / Solaris
[root@c9n2 ~]# iscsiadm -m node
iscsiadm: no records found!
[root@c9n2 ~]# iscsiadm -m discovery -t sendtargets -p 172.17.109.254
[root@c9n2 ~]# iscsiadm -m discovery -t sendtargets -p 172.17.209.254
[root@c9n2 ~]# service iscsi restart
Setting up iSCSI targets: Logging in to [iface: default, target: iqn.2010-
11.com.example.cluster9:iscsi, portal: 172.17.209.254,3260]
portal: 172.17.109.254,3260]
172.17.209.254,3260]: successful
172.17.109.254,3260]: successful
[...]
/dev/sda3 383 385 15438 83 Linux
Disk /dev/sdb: 5368 MB, 5368709120 bytes
/dev/sdb3 383 385 15438 83 Linux
Quitar de la blacklist los dispositivos comentandolos
[root@c9n2 ~]# vi /etc/multipath.conf
create: mpath0 (S_beaf11) IET,VIRTUAL-DISK
[size=5.0G][features=0][hwhandler=0][n/a]

\_ 0:0:0:1 sda 8:0 [undef][ready]
\_ 1:0:0:1 sdb 8:16 [undef][ready]
mkqdisk v0.6.0
/dev/dm-4:
/dev/mapper/mpath0p3:
/dev/mpath/mpath0p3:
Magic: eb7a62c2
Label: mydisk
Created: Thu Dec 2 11:14:19 2010
Host: c9n1.example.com
Kernel Sector Size: 512
Recorded Sector Size: 512
[root@c9n2 ~]# service qdiskd start

[root@c9n2 ~]# chkconfig qdiskd on
Ahora vemos el estado del cluster
[root@c9n1 ~]# clustat -i 1
Cluster Status for cluster9 @ Thu Dec 2 11:44:30 2010
Member Status: Quorate
Member Name ID Status
------ ---- ---- ------
node1.cluster9.example.com 2 Online, Local,
rgmanager
node3.cluster9.example.com 3 Offline,
Estranged
/dev/dm-4 0 Online, Quorum
Disk
State
------- ---- ----- ------
-----
service:webby
node2.cluster9.example.com started
[root@c9n1 ~]# cman_tool status
Nodes: 2
Expected votes: 3
Quorum device votes: 1
Total votes: 3
Quorum: 2
8. GRUPOS DE RECURSOS
El componente clave de la administración de servicios de alta disponibilidad en un cluster de Red

Hat es rgmanager. Este componente implementa recuperación contra fallos para aplicaciones. En
un cluster de Red Hat, una aplicación es configurada con otros recursos del cluster para formar
un servicio de cluster de alta disponibilidad. Un servicio de cluster consta de recursos de cluster.

Los recursos de cluster son bloques de construcción que se crean y administran en el archivo de
configuración de cluster (por ejemplo, una dirección IP, el script de inicialización de una aplicación o
una partición compartida Red Hat GFS).
8.1. rgmanager
rgmanager proveee "cold failover" (normalmente significa que se hace un reinicio total de todas
las aplicaciones) para aplicaciones externas (off-the-shelf) y luego hace un "heavy lifting " del que
participan en los grupos de recursos o el failover del sistema. icio. Los servicios pueden aprovechar la
extensibilidad del cluster mediante comandos de la API, o
con un script de inicio SysV lo que acepte los argumentos “start, stop, restart, and status”
Sin rgmanger, cuando un nodo que ejecuta un servicio falla y por tanto, se le hace fencing (es parado
y aislado) el servicio que estaba corriendo seguirá sin estar disponible hasta que el nodo vuelva a
estar online. rgmanager usa OpenAIS para “hablar” con la infraestructura del cluster, y usa un modelo
distribuído para obtener información sobre el estado de los grupos de recursos o servicios.
No siempre es deseable que un servicio (o un grupo de recuros) haga failover a un nodo en particular.
rgmanager se registra como un “servicio” con CMAN:

# cman_tool services
type level name id state
fence 0 default 00010003 none
[1 2 3]
dlm 1 rgmanager 00030003 none
[1 2 3]
8.2. INICIO Y PARADA DE GRUPOS DE RECURSOS
Dentro de un grupo de recursos, el oden de inicio y parada cuando se habilita un servicio es muy
importante. ¿Debería Apache iniciarse antes de que su DocumentRoot esté montado? ¿Debería
levantarse la IP de un servidor NFS antes de que los clientes permitidos se hayan definido? Hay varios
recursos “especiales” que tienen ordenes de arranque y parada predefinidos en sun configuración.
En /usr/share/cluster/service.sh podemos ver los ordenes predefinidos para los grupos de recursos:
<special tag="rgmanager">
<attributes root="1" maxinstances="1"/>
<child type="fs" start="1" stop="8"/>
<child type="clusterfs" start="2" stop="7"/>
<child type="netfs" start="3" stop="6"/>
<child type="nfsexport" start="4" stop="5"/>
<child type="nfsclient" start="5" stop=""/>
<child type="ip" start="6" stop="2"/>
<child type="smb" start="7" stop="3"/>
<child type="script" start="7" stop="1"/>
</special>
Se puede ver que los distintos grupos de recursos tienen distintas prioridades de inicio y parada

cuando se usan dentro del mismo grupo de recursos. El orden por relaciones jerárquicas puede
establecerse también desde la GUI.
Después de que se haya arrancado un recurso, sigue bajando por su estructura de árbol en memoria
que se haya definido por reglas XML externas y pasadas a CCS, para arrancar todas sus dependencias
jerárquicas. Antes de parar un recurso, se han de parar todos sus hijos primero. Según esta estructura,
es posible hacer modificaciones a servicios online e inteligentemente añadir o reiniciar recursos hijo
(como un recurso cliente NFS) sin afectar al padre (el recurso export NFS).
Por ejemplo, un subpunto de montaje:

Incorrecto:
<service ... >
<fs mountpoint="/a" ... />
<fs mountpoint="/a/b" ... />
<fs mountpoint="/a/c" ... />
</service>
Correcto:
<service ... >
<fs mountpoint="/a" ... >
<fs mountpoint="/a/b" ... />
<fs mountpoint="/a/c" ... />
</fs>
</service>
En el ejemplo correcto “/a” se monta antes que los otros, no se garantiza el orden de montado
siguiente, puede ser “/a/b” o “/a/c”, pero eso no nos afecta. Además, “/a” no se desmontará hasta que
sus hijos se hayan desmontado primero.
9.- GFS Y CLVM
9.1. GFS
Red Hat GFS es un sistema de archivos de cluster que permite que los nodos de un cluster tengan
acceso simultáneo a un dispositivo de bloque compartido. GFS es un sistema de archivos nativo que
interactúa directamente con la capa VFS de la interfaz del sistema de archivos del kernel de Linux. GFS
utiliza metadatos distribuidos y varios diarios de registro (journals) para asegurar la óptima operación
en un cluster. Para mantener la integridad del sistema de archivos, GFS utiliza un cierre de exclusión
mutua para coordinar las operaciones de E/S. Cuando un nodo cambia los datos en el sistema de
archivos GFS, estos son inmediatamente visibles desde los otros nodos del cluster que utilizan el
sistema de archivos.
Con Red Hat GFS se puede obtener el mayor tiempo de funcionamiento de una aplicación a través de
los siguientes beneficios:
* Simplifica la infraestructura de los datos

o Permite la instalación de aplicaciones para todo el cluster.
o Elimina la necesidad de copias innecesarias de los datos de la aplicación
(duplicación)

o Permite acceso de lectura y escritura concurrente a los datos de varios
clientes.
o Simplifica la creación de copias de seguridad y la recuperación contra
desastres (sólo un sistema de archivos debe ser copiado o recuperado).
* Maximiza el uso de recursos de almacenamiento; minimiza los costos de
administración de almacenamiento.
o Administra el almacenamiento como un todo y no como particiones.
o Decrece el almacenamiento general al eliminar la necesidad de duplicación de
datos.
* Escala el cluster al añadir servidores o almacenamiento en la marcha.
o Evita el particionamiento de almacenamiento a través de técnicas complicadas.
o Añade servidores al cluster montándolos en el sistema de archivos común.
Los nodos que ejecutan Red Hat GFS son configurados y administrados con las herramientas de
configuración y administración de Red Hat Cluster Suite. La administración de volúmenes se realiza
a través de CLVM (Cluster Logical Volume Manager). Red Hat GFS proporciona compartición de datos
entre los nodos GFS en un cluster de Red Hat. GFS proporciona un panorama consistente y único
de los espacios de nombre del sistema de archivo a los largo de los nodos GFS en un cluster de Red
Hat. GFS permite que las aplicaciones sean instaladas y ejecutadas sin necesidad de un conocimiento
detallado de la infraestructura de almacenamiento. Asimismo, GFS proporciona funcionalidades que
son típicamente requeridas en entornos empresariales, tales como quotas, varios diarios de registro y
soporte de múltiples rutas.
GFS proporciona un método versátil del almacenamiento de red de acuerdo con el rendimiento,
escalabilidad y economía necesarias en su entorno de almacenamiento. Este capítulo proporciona
información básica y abreviada para ayudar al lector a entender GFS.
9.2.1 Características
Requiere los elementos del núcleo de Cluster Suite para funcionar:
• OpenAIS para la comunicación entre nodos.
• CLVMD para distribuir las actualizaciondes de los metadatos a los nodos
• I/O Fencing subsystem (fenced)
• Cluster Configuration System (CCS)
• Cluster Manager (CMAN)
• GFS-specific component:
• Distributed Lock Manager (DLM)
9.2.2 Tareas de configuración inicial

La configuración inicial de GFS2 está conformada por las siguientes tareas:
1. Configuración de volúmenes lógicos.

2. Creación del sistema de archivos GFS2.
3. Montaje del sistema de archivos.
9.2.3 CREACIÓN DE UN SISTEMA DE FICHEROS GFS
Información requerida:
• Tipo de gestor de bloqueos (lock_nolock, lock_dlm)
• Nombre de fichero de bloque (cluster_name:fs_name)
• Número de journals, uno por cada nodo que acceda al GFS (mínimo, extras son útiles para escalar).
• Tamaño de los journals.
• Tamaño de bloque del sistema de ficheros.
Ejemplo: gfs_mkfs -p lock_dlm -t cluster1:gfslv -j 3 /dev/vg0/gfslv
El siguiente es un ejemplo de un sistema de ficheros GFS que usa gestión de bloqueos DLM, es un
recurso válido del cluster llamado “cluster1” y se coloca en un volúmen lógico llamado “gfslv” que ha
sido creado desde un grupo de volúmenes llamado “vg0” y crea 3 journals, cada uno de ellos ocupa
128Mb de espacio.
# gfs_mkfs -p lock_dlm -t cluster1:gfslv -j 3 /dev/vg0/gfslv
El fichero de lock consiste en 2 elementos delimitados por ‘:’ el nombre del cluster y un nombre para el
FS de hasta 16 caracteres único.
Todos los atributos de un sistema de ficheros GFS pueden ser obtenidos (siempre que el FS esté
montado) con:
#gfs_tool df <GFS_mount_point>
El tamaño del journal se especifica con la opción -j y por defecto es 128Mb (si bien el mínimo
especificable son 32Mb). El tamaño del bloque de GFS se especifica con -b y por defecto con 4096
bytes. El tamaño del bloque es una potencia de 2 entre 512bytes y el tamaño de página de la máquina
(normalmente 4096 bytes).
• Ver el número de journals existentes:

gfs_tool jindex /gfsdata | grep Journal
• Ver si hay más espacio para añadir 2 journals:
gfs_jadd -Tv -j 2 /gfsdata
• Añadir 2 nuevos journals:
gfs_jadd -j 2 /gfsdata
Añadir journals extra puede facilitar el crecimiento del sistema de ficheros.
9.2.4 Aumentar un Sistema de Ficheros GFS
Para aumentar un sistema de ficheros GFS, el volúmen lógico subyaciente ha de aumentarse antes.
Puesto que los bloques de datos del sistema de ficheros no puede convertirse a espacio de journal (si
bien GFS2 sí es capaz) cualquier journal que se necesite ha de crearse antes de crecer el sistema de

ficheros GFS.
Pasos:
1. Crear volumenes físicos adicionales:
# pvcreate /dev/sdc /dev/sdd
2. Extender el grupo de volumenes acutales:
# vgextend vg0 /dev/sdc /dev/sdd
3. Extender el volumen lógico:
# vextend -L +100G /dev/vg0/gfslv
4. Crecer el sistema de ficheros GFS existente dentro del espacio adicional:
# gfs_grow -v <DEVICE|MOUNT_POINT>
9.2.5. ATRIBUTOS EXTENDIDOS DE GFS.
9.2.5.1. ACLs
El sistema de ficheros en el que se van a implementar ACLs ha de estar montado con la opción ‘acl’
(bien en /etc/fstab o bien en línea de comandos). Las ACLs añaden usuarios y grupos adicionales .
Ejemplo: Añadir permisos rw al usuario ‘boss’ y un usario concreto del grupo users llamado ‘joe’ no ha
de tener ningún tipo de acceso.
-rw-r----- 1 jane users 0 Dec 17 18:33 data.0
# setfacl -m u:boss:rw,u:joe:- data.0
Puesto que las máscaras de permisos de usuarios se comprueban antes que las de grupo, el que el
usuario joe pertenezca al grupo no tiene efecto (nunca llega a comprobarse, dado que se identifica a
joe como un usuario sin permisos).
Para ver la configuración de ACLs de un fichero o directorio se usa getfacl y para cambiarlas, setfacl.
9.2.5.2. PARÁMETROS AJUSTABLES
Hay muchos parámetros asosciados con un sistema de ficheros GFS que se pueden modificar con el
comando gfs_tool settune. Los parámetros ajustables han de ser configurados en cada nodo que va a
montar el sistema de ficheros. Dichos parámetros no son persistentes a reinicios.
Para poder ver todos los parámetros ajustables usamos el comando gfs_tool gettune:
[root@tng3-1]# gfs_tool gettune /mnt/gfs
ilimit1 = 100
ilimit1_tries = 3
ilimit1_min = 1
ilimit2 = 500
ilimit2_tries = 10
ilimit2_min = 3
demote_secs = 300
incore_log_blocks = 1024
jindex_refresh_secs = 60
depend_secs = 60
scand_secs = 5

recoverd_secs = 60
logd_secs = 1
quotad_secs = 5
inoded_secs = 15
glock_purge = 0
quota_simul_sync = 64
quota_warn_period = 10
atime_quantum = 3600
quota_quantum = 60
quota_scale = 1.0000 (1, 1)
quota_enforce = 1
quota_account = 1
new_files_jdata = 0
new_files_directio = 0
max_atomic_write = 4194304
max_readahead = 262144
lockdump_size = 131072
stall_secs = 600
complain_secs = 10
reclaim_limit = 5000
entries_per_readdir = 32
prefetch_secs = 10
statfs_slots = 64
max_mhc = 10000
greedy_default = 100
greedy_quantum = 25
greedy_max = 250
rgrp_try_threshold = 100
statfs_fast = 0
Cada inodo de fichero y/o directorio tiene 3 marcas de tiempo asosiadas:
ctime: Última vez que los metadatos del inodo fueron modificados.
mtime: Última vez que el fichero o directorio fue modificado.
atime: Última vez que los datos del fichero o directorio fueron accedidos.
Para poder verlos, usaremos el comando:
# gfs_tool stat <filename>
Podemos desactivar las actualizaciones de ‘atime’ montando el FS con la opción ‘noatime’:

# mount -t gfs -o noatime /dev/vg0/lv1 /gfsdata
También podemos ajustar la frecuencia de las actualizaciones de ‘atime’ con gfs_tool modificando el
parámetro atime_quantum:
# gfs_tool settune /gfsdata atime_quantum 86400
En caso de que un FS se corrompa, podemos intentar volver a un estado consistente con gfs_fsck. Este
comando ha de ejecutarse en un FS desmontado en todos los nodos:
# gfs_fsck <block_device>
Por ejemplo, para buscar inconsistencias en el FS y automáticamente llevar a cabo los cambios
necesarios sin preguntar:
# gfs_fsck -y /dev/vg0/lv1

9.3. GESTIÓN DE QUOTAS
Las quotas de FS sirven para limitar la cantidad de espacio en disco que un usuario o grupo pueden
usar. Los updates de GFS son transaccionales, por tanto, un fallo del sistema no implica que haya que
recontruir las quotas.
Para evitar que el rendimiento se vea impactado, los nodos GFS sincronizan sus actualizaciones de
manera periódica. GFS reduce dramáticamente el periodo de sincronización según se acerque al
límite ‘hard’. El comando usado para gestionar quotas es gfs_quota.
Configuración de quotas, límite hard:

# gfs_quota limit -u User -l Size -f PtoMontaje
# gfs_quota limit -g Group -l Size -f PtoMontaje
Configuración de quotas, límite warn:
# gfs_quota warn -u User -l Size -f PtoMontaje
# gfs_quota warn -g Group -l Size -f PtoMontaje
Mostrar las quotas para un usuario:
# gfs_quota get -u User -f MountPoint
Mostrar las quitas para un grupo:
# gfs_quota get -g Group -f MountPoint
Mostrar todas las quotas de un fichero o directorio:
# gfs_quota list -f MountPoint
Sincronizar la información de las quotas:
# gfs_quota sync -f MountPoint
Ejemplos:
Mostrar la información de las quotas para todos los usuarios y grupos que tiene un límite o están
usando espacio en disco del FS bajo /gfs:
[root@ask-07 ~]# gfs_quota list -f /gfs
user root: limit: 0.0 warn: 0.0 value: 0.2
user moe: limit: 1024.0 warn: 0.0 value: 0.0
group root: limit: 0.0 warn: 0.0 value: 0.2
group stooges: limit: 0.0 warn: 0.0 value: 0.0
Mostrar la información de quota en sectores para el grupo ‘users’ en el FS bajo /gfs:

[root@ask-07 ~]# gfs_quota get -g users -f /gfs -s
group users: limit: 0 warn: 96 value: 0
Sincronizar la información de quotas del nodo que ejecuta el FS /gfs:

# gfs_quota sync -f /gfs
Cambiar el período de tiempo predeterminado entre actualizaciones periódicas de archivos con cuotas
a una hora (3600 segundos) para el sistema de archivos / GFS en un solo nodo.
# gfs_tool settune /gfs quota_quantum 3600
9.4. Administrador de volúmenes lógicos en cluster (CLVM)

El administrador de volúmenes lógicos en cluster (CLVM) es un conjunto de extensiones para LVM.
Estas extensiones permiten que un cluster de computadores administre el almacenamiento
compartido (por ejemplo, en un SAN) a través de LVM.
El uso de CLVM depende de los requisitos del sistema:
● Si sólo un nodo del sistema requiere acceder al almacenamiento que está configurando como
volúmenes lógicos, entonces puede utilizar LVM sin las extensiones de CLVM y los volúmenes
lógicos creados con ese nodo son todos locales al nodo.
● Si se está utilizando un sistema en cluster para recuperación de fallos donde únicamente un
solo nodo que accede al almacenamiento está activo a cualquier momento, habrá que utilizar
los agentes de alta disponibilidad de administración de volúmenes lógicos (HA-LVM).
● Si más de un nodo del cluster requiere acceder al almacenamiento, el cual es compartido entre
los nodos activos, entonces habrá que utilizar CLVM. CLVM permite configurar volúmenes
lógicos en almacenamiento compartido al bloquear el acceso al almacenamiento físico mientras
el volumen lógico está siendo configurado. CLVM utiliza servicios de bloqueo en cluster para
administrar el almacenamiento compartido.
Para utilizar el CLVM, debe estar ejecutándose el software de Red Hat Cluster Suite, incluyendo el
demonio clmvd. El demonio clmvd es la extensión principal de cluster para LVM. El demonio clvmd se
ejecuta en cada computador del cluster y distribuye las actualizaciones de metadatos de LVM en un
cluster, presentando cada computador del cluster con el mismo panorama de volúmenes lógicos. Para
asegurarse de que clmvd se inicie en el arranque, puede ejecutar un comando chkconfig ... on en el
servicio clvmd, así:
# chkconfig clvmd on
Si el demonio clvmd no se ha iniciado, puede ejecutar un comando service ... start en el servicio clvmd,
así:
# service clvmd start

Apuntes RH436

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Apuntes RH436

Uploaded by

Copyright:

Available Formats

1.

- GESTIÓN DE DATOS, ALMACENAMIENTO Y TECNOLOGÍA

1.1 ¿QUÉ ES UN CLUSTER?

Lo que distingue un cluster de alta disponibilidad (HA) de un cluster de balanceo de carga es la

1.2. TOPOLOGÍA DE CLUSTER

Red Hat Enterprise Clustering and Storage Management

1.3. MODELO DE ALMACENAMIENTO DE RHEL

Red Hat Enterprise Clustering and Storage Management

LUN: Logical Unit Number, identificador único dentro de la cabina.

[root@station9 ~]# blkid

1.5. ACCESO A VOLUMENES DE DATOS

1.5.1 SAN, STORAGE AREA NETWORK

Componentes típicos de una red de fibra son:

Red Hat Enterprise Clustering and Storage Management

1.5.2 NAS, NETWORK ATTACHED STORAGE

Es el nombre dado a una tecnología de almacenamiento dedicada a compartir la capacidad de

A diferencia de SAN, NAS ofrece la garantía de la coherencia de datos.

1.6. REDES DE NODOS DE CLUSTER.

Red Hat Enterprise Clustering and Storage Management

[root@station9 ~]# netstat -g

1.7. BONDING ETHERNET

Pasos para configurarlo:

2.- Configurar los interfaces de bonding.

Red Hat Enterprise Clustering and Storage Management

Bonding no hace fail-back (obviamente, sí hace fail-over) si se pone el parámetro “primary=interfaz” sí

1.9. SEGURIDAD DEL CLUSTER

PORT NUMBER SERVICE PROTOCOL

Red Hat Enterprise Clustering and Storage Management

Los números major y minor son irrelevantes para udev.

2.1. HAL, HARDWARE ABSTRACTION LAYER

Red Hat Enterprise Clustering and Storage Management

2.2. CADENA DE EVENTOS PARA UN NUEVO DISPOSITIVO ENCHUFADO

1. El kernel descubre el dispositivo y exporta su estado al sysfs.

En este curso nos centraremos en los 3 primeros eventos unicamente.

[root@station9 rules.d]# udevinfo -q name -p /sys/block/sdb

Red Hat Enterprise Clustering and Storage Management

El comando udevinfo -a dispositivo nos da toda la información relativa a dicho dispositivo en la

En el siguiente ejemplo, al dispositivo USB con el SN 20043512321411d34721 se le asignará un enlace

Ej: BUS=="usb", SYSFS{serial}=="20043512321411d34721", SYMLINK+="usb_backup"

[root@station9 rules.d]# scsi_id -g -s /block/sda

Red Hat Enterprise Clustering and Storage Management

[root@station9 rules.d]# cd /dev/disk/

[root@station9 disk]# vi /etc/udev/rules.d/75-classlab_local.rules

Obtengo información de mi dispositivo

Red Hat Enterprise Clustering and Storage Management

[root@station9 ~]# udevinfo -a -p /block/sdb | grep serial

Red Hat Enterprise Clustering and Storage Management

Red Hat Enterprise Clustering and Storage Management

Los pasos para configurar los targets:

El fichero /etc/tgt/targets.conf tiene las siguientes opciones principales:

backing-store device defines a virtual device on the target.

initiator-address address Limits access to only the specified IP address. Defaults

incominguser username Only specified user can connect.

3.1. CONFIGURACIÓN DEL CLIENTE (iSCSI INITIATOR)

El fichero de configuración del cliente es /etc/iscsi/iscsid.conf. La configuración por defecto

Red Hat Enterprise Clustering and Storage Management

Los ficheros de configuración son:

3.2. CONEXIÓN POR PRIMERA VEZ A UN TARGET iSCSI

1. Iniciar el servicio initiator (el demonio):

Para borrar el registro del target:

Red Hat Enterprise Clustering and Storage Management

2. Configurar los nodos clientes

Red Hat Enterprise Clustering and Storage Management

3. Crear una regla udev en node1