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 -gIPv6/IPv4 Group MembershipsInterface RefCnt Group--------------- ------ ---------------------lo 1 ALL-SYSTEMS.MCAST.NETcluster 1 224.0.0.251cluster 1 ALL-SYSTEMS.MCAST.NETstorage1 1 224.0.0.251storage1 1 ALL-SYSTEMS.MCAST.NETstorage2 1 224.0.0.251storage2 1 ALL-SYSTEMS.MCAST.NETvirbr0 1 224.0.0.251virbr0 1 ALL-SYSTEMS.MCAST.NETeth0 1 224.0.0.251eth0 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.confvi /etc/modprobe.confalias bond0 bondingoptions bond0 mode=1 miimon=100 use_carrier=0

2.- Configurar los interfaces de bonding.cd /etc/sysconfig/network-scriptsvi ifcfg-bond0-----------DEVICE=bond0IPADDR=192.0.2.1NETMASK=255.255.255.0GATEWAY=192.0.2.254ONBOOT=yesBOOTPROTO=staticBONDING_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-scriptsvi ifcfg-eth0-------------DEVICE=eth0MASTER=bond0SLAVE=yes


ONBOOT=yesBOOTPROTO=static vi ifcfg-eth1--------------DEVICE=eth1MASTER=bond0SLAVE=yesONBOOT=yesBOOTPROTO=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 PROTOCOL5404, 5405 cman udp11111 ricci tcp14567 gnbd tcp16851 modclusterd (part of Conga) tcp21064 dlm tcp50006, 50008, ccsd tcp5000950007 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 /devudev 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/sdbsdb[root@station9 rules.d]# udevinfo -q all -p /sys/block/sdbP: /block/sdbN: sdbS: disk/by-id/usb-S31B1010_USB_DISK_AA330463000360007269S: disk/by-path/pci-0000:00:1d.7-usb-0:8:1.0-scsi-0:0:0:0E: ID_VENDOR=S31B1010E: ID_MODEL=USB_DISKE: ID_REVISION=1100E: ID_SERIAL=S31B1010_USB_DISK_AA330463000360007269


E: ID_TYPE=diskE: ID_BUS=usbE: 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/sdbP: /block/sdbN: sdbS: disk/by-id/usb-S31B1010_USB_DISK_AA330463000360007269S: disk/by-path/pci-0000:00:1d.7-usb-0:8:1.0-scsi-0:0:0:0E: ID_VENDOR=S31B1010E: ID_MODEL=USB_DISKE: ID_REVISION=1100E: ID_SERIAL=S31B1010_USB_DISK_AA330463000360007269E: ID_TYPE=diskE: ID_BUS=usbE: ID_PATH=pci-0000:00:1d.7-usb-0:8:1.0-scsi-0:0:0:0

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/sdaSATA ST380815AS 6RX25Y65 [root@station9 rules.d]# scsi_id -g -u -s /block/sdaSATA_ST380815AS_6RX25Y65_[root@station9 rules.d]# scsi_id -g -u -x -s /block/sdaID_VENDOR=ATAID_MODEL=ST380815ASID_REVISION=3.CHID_SERIAL=SATA_ST380815AS_6RX25Y65ID_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]# lsby-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-part2by-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-part3by-path/pci-0000:00:1f.1-ide-0:0 by-path/pci-0000:00:1f.2-scsi-0:0:0:0-part4by-path/pci-0000:00:1f.2-scsi-0:0:0:0 by-path/pci-0000:00:1f.2-scsi-0:0:0:0-part5by-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-part4by-id/scsi-SATA_ST380815AS_6RX25Y65-part1 by-id/scsi-SATA_ST380815AS_6RX25Y65-part5by-id/scsi-SATA_ST380815AS_6RX25Y65-part2 by-id/usb-S31B1010_USB_DISK_AA330463000360007269by-id/scsi-SATA_ST380815AS_6RX25Y65-part3 by-id/usb-S31B1010_USB_DISK_AA330463000360007269-part1

Ejercicios1.- Crear un nuevo dispositivo con las siguientes reglas:Owner: studentGroup: studentMode: 0600Name: /dev/sda6 [root@station9 disk]# vi /etc/udev/rules.d/75-classlab_local.rulesKERNEL=="sda6", OWNER="student", GROUP="student", MODE="0600"[root@station9 disk]# partprobe /dev/sda[root@station9 disk]# ll /dev/sda6brw------- 1 student student 8, 6 Nov 29 15:38 /dev/sda6

2.- Crear una regla para un pendrive USB con los siguientes atributos:Owner: studentGroup: studentMode: 0600Name: /dev/sda6 Obtengo información de mi dispositivo[root@station9 disk]# udevinfo -q all -n /dev/sdbP: /block/sdbN: sdbS: disk/by-id/usb-S31B1010_USB_DISK_AA330463000360007269S: disk/by-path/pci-0000:00:1d.7-usb-0:8:1.0-scsi-0:0:0:0E: ID_VENDOR=S31B1010E: ID_MODEL=USB_DISKE: ID_REVISION=1100E: ID_SERIAL=S31B1010_USB_DISK_AA330463000360007269


E: ID_TYPE=diskE: ID_BUS=usbE: ID_PATH=pci-0000:00:1d.7-usb-0:8:1.0-scsi-0:0:0:0 [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.rulesKERNEL=="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/sdbbrw------- 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 -s5. 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 password

Only specified user can connect.

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 initiator-address 172.17.120.2 initiator-address 172.17.120.3</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 iqn.2010-11.com.example.cluster9:iscsi> backing-store /dev/vol0/iscsi initiator-address 172.17.109.1 initiator-address 172.17.109.2 initiator-address 172.17.109.3</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 -sTarget 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.254172.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-871node.name = iqn.2010-11.com.example.cluster9:iscsinode.tpgt = 1node.startup = automaticiface.hwaddress = <empty>iface.ipaddress = <empty>


iface.iscsi_ifacename = defaultiface.net_ifacename = <empty>iface.transport_name = tcpiface.initiatorname = <empty>node.discovery_address = 172.17.109.254node.discovery_port = 3260node.discovery_type = send_targetsnode.session.initial_cmdsn = 0node.session.initial_login_retry_max = 8node.session.xmit_thread_priority = -20[...]# END RECORD

Toda esta información se encuentra en el directorio /var/lib/iscsiHacemos login en el target iSCSI[root@node1 ~]# iscsiadm -m node -T iqn.2010-11.com.example.cluster9:iscsi -p 172.17.109.254 -lLogging 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 bytes166 heads, 62 sectors/track, 1018 cylindersUnits = cylinders of 10292 * 512 = 5269504 bytes

Borramos el target iSCSI[root@node1 ~]# iscsiadm -m node -T iqn.2010-11.com.example.cluster9:iscsi -p 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/sdaS_beaf11[root@node1 class]# vi /etc/udev/rules.d/75-classlab_remote.rulesKERNEL=="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 divididoUn 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 espejoUn 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.

Para crear un RAID 1 por software:#mdadm --create /dev/md0 --level=1 --raid-devices=2 /dev/sd[ab]1Podemos 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 distribuidaUn 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.


Para crear un RAID 5 por software:#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).

Para crear un RAID 6 por software:#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 espejosUn 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.Para crear un RAID 10 por software:#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/mdadmmdadm-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 [email protected]

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] Ejercicios1. 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/dev/sda8 4274 4335 498014+ fd Linux raid autodetect/dev/sda9 4336 4397 498014+ fd Linux raid autodetect/dev/sda10 4398 4459 498014+ fd Linux raid autodetect[root@station9 ~]# partprobe[root@station9 ~]# mdadm --create /dev/md0 --level=1 --raid-devices=2 /dev/sda{7,8} --auto=yesmdadm: array /dev/md0 started.[root@station9 ~]# mdadm --create /dev/md1 --level=1 --raid-devices=2 /dev/sda{9,10} --auto=yes -b internalmdadm: array /dev/md1 started.[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]md0 : active raid1 sda8[1] sda7[0] 497920 blocks [2/2] [UU]unused devices: <none>

Simulamos fallos en los arrays:[root@station9 ~]# mdadm /dev/md0 --fail /dev/sda7 --remove /dev/sda7mdadm: set /dev/sda7 faulty in /dev/md0mdadm: hot removed /dev/sda7[root@station9 ~]# watch -n .2 'cat /proc/mdstat'md0 : active raid1 sda8[1] 497920 blocks [2/1] [_U][root@station9 ~]# dd if=/dev/urandom of=/data0/fichero bs=1M count=1010+0 records in10+0 records out10485760 bytes (10 MB) copied, 2.10135 seconds, 5.0 MB/s[root@station9 ~]# mdadm /dev/md0 --add /dev/sda7mdadm: re-added /dev/sda7[root@station9 ~]# watch -n .2 'cat /proc/mdstat'


md0 : active raid1 sda7[0] sda8[1] 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[root@node1 ~]# fdisk -l/dev/hda5 340 352 104391 fd Linux raid autodetect/dev/hda6 353 365 104391 fd Linux raid autodetect/dev/hda7 366 378 104391 fd Linux raid autodetect[root@node1 ~]# partprobe[root@node1 ~]# mdadm --create /dev/md0 --level=5 --raid-devices=3 /dev/hda{5,6,7}mdadm: array /dev/md0 started.[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 2010Personalities : [raid6] [raid5] [raid4]md0 : active raid5 hda7[2] hda6[1] hda5[0] 208640 blocks level 5, 64k chunk, algorithm 2 [3/3] [UUU]unused devices: <none>

Ahora fallamos y verificamos el RAID5.[root@node1 ~]# mdadm /dev/md0 --fail /dev/hda5 --remove /dev/hda5mdadm: set /dev/hda5 faulty in /dev/md0mdadm: hot removed /dev/hda5Every 0.2s: cat /proc/mdstat

Tue Nov 30 12:47:12 2010Personalities : [raid6] [raid5] [raid4]md0 : active raid5 hda7[2] hda6[1] 208640 blocks level 5, 64k chunk, algorithm 2 [3/2] [_UU]unused devices: <none>[root@node1 ~]# mdadm /dev/md0 --fail /dev/hda6 --remove /dev/hda6mdadm: set /dev/hda6 faulty in /dev/md0mdadm: hot removed /dev/hda6Every 0.2s: cat /proc/mdstat

Tue Nov 30 12:48:28 2010Personalities : [raid6] [raid5] [raid4]md0 : active raid5 hda7[2] 208640 blocks level 5, 64k chunk, algorithm 2 [3/1] [__U]unused devices: <none>

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/algotouch: 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/hda5mdadm: re-added /dev/hda5Every 0.2s: cat /proc/mdstat

Tue Nov 30 13:02:35 2010Personalities : [raid6] [raid5] [raid4]md0 : active raid5 hda5[0](S) hda7[2] 208640 blocks level 5, 64k chunk, algorithm 2 [3/1] [__U]unused devices: <none>[root@node1 ~]# umount /dev/md0[root@node1 ~]# mdadm --stop /dev/md0mdadm: stopped /dev/md0[root@node1 ~]# mdadm --assemble /dev/md0 /dev/hda{5,6,7} --forcemdadm: forcing event count in /dev/hda6(1) from 8 upto 16mdadm: /dev/md0 has been started with 2 drives (out of 3).

Creamos un RAID6 con otras 4 particiones[root@node1 ~]# fdisk -l /dev/hda/dev/hda8 379 391 104391 fd Linux raid autodetect/dev/hda9 392 404 104391 fd Linux raid autodetect/dev/hda10 405 417 104391 fd Linux raid autodetect/dev/hda11 418 430 104391 fd Linux raid autodetect[root@node1 ~]# mdadm --create /dev/md1 --level=6 --raid-devices=4 /dev/hda{8,9,10,11} --auto=yesmdadm: array /dev/md1 started.Every 0.2s: cat /proc/mdstat

Tue Nov 30 13:08:30 2010Personalities : [raid6] [raid5] [raid4]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[root@node1 ~]# mdadm /dev/md1 --fail /dev/hda8 --remove /dev/hda8mdadm: set /dev/hda8 faulty in /dev/md1mdadm: hot removed /dev/hda8[root@node1 ~]# mdadm /dev/md1 --fail /dev/hda9 --remove /dev/hda9mdadm: set /dev/hda9 faulty in /dev/md1mdadm: hot removed /dev/hda9Every 0.2s: cat /proc/mdstat

Tue Nov 30 13:16:25 2010Personalities : [raid6] [raid5] [raid4]md1 : active raid6 hda11[3] hda10[2] 208640 blocks level 6, 64k chunk, algorithm 2 [4/2] [__UU]


[root@node1 ~]# cat /raid6/pruebaraid6[root@node1 ~]# touch /raid6/hola

Recuperamos los discos del array[root@node1 ~]# mdadm /dev/md1 --add /dev/hda8mdadm: re-added /dev/hda8[root@node1 ~]# mdadm /dev/md1 --add /dev/hda9mdadm: re-added /dev/hda9

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.confARRAY /dev/md0 level=raid5 num-devices=3 UUID=7d0da1d3:49b32c29:cd4a22e3:eebfa7c2 devices=/dev/hda7,/dev/hda6,/dev/hda5 spare-group=amayaARRAY /dev/md1 level=raid6 num-devices=4 UUID=7ca3b11a:62882f07:6829a892:46d7762a devices=/dev/hda11,/dev/hda10,/dev/hda9,/dev/hda8 spare-group=amayaMAILADDR root

Creamos una nueva partición y la añadimos como hot spare[root@node1 ~]# mdadm /dev/md0 --add /dev/hda12mdadm: added /dev/hda12Every 0.2s: cat /proc/mdstat

Tue Nov 30 13:24:49 2010md0 : active raid5 hda12[3](S) hda5[0] hda6[1] hda7[2] 208640 blocks level 5, 64k chunk, algorithm 2 [3/3] [UUU]unused devices: <none>

Configurar mdmonitor[root@node1 ~]# vi /etc/mdadm.confMAILADDR root[root@node1 ~]# chkconfig mdmonitor on[root@node1 ~]# service mdmonitor restart

Automáticamente el disco hot spare del RAID5 ha migrado al RAID6.Every 0.2s: cat /proc/mdstat

Tue Nov 30 13:30:55 2010Personalities : [raid6] [raid5] [raid4]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/secmd0 : active raid5 hda5[0] hda6[1] hda7[2] 208640 blocks level 5, 64k chunk, algorithm 2 [3/3] [UUU]unused devices: <none>

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/sda2 192 382 982886 fd Linux raid autodetect/dev/sda3 383 573 982886 fd Linux raid autodetect/dev/sda4 574 1018 2289970 5 Extended/dev/sda5 574 764 982855 fd Linux raid autodetect

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/sda1mdadm: added /dev/sda1[root@node1 ~]# mdadm /dev/md1 --fail /dev/hda9 --remove /dev/hda9mdadm: set /dev/hda9 faulty in /dev/md1mdadm: hot removed /dev/hda9[root@node1 ~]# mdadm /dev/md1 --add /dev/sda2mdadm: added /dev/sda2[root@node1 ~]# mdadm /dev/md1 --fail /dev/hda10 --remove /dev/hda10mdadm: set /dev/hda10 faulty in /dev/md1mdadm: hot removed /dev/hda10[root@node1 ~]# mdadm /dev/md1 --add /dev/sda3mdadm: added /dev/sda3[root@node1 ~]# mdadm /dev/md1 --fail /dev/hda11 --remove /dev/hda11mdadm: set /dev/hda11 faulty in /dev/md1mdadm: hot removed /dev/hda11[root@node1 ~]# mdadm /dev/md1 --add /dev/sda5mdadm: added /dev/sda5[root@node1 ~]# mdadm /dev/md1 --fail /dev/hda12 --remove /dev/hda12mdadm: set /dev/hda12 faulty in /dev/md1mdadm: hot removed /dev/hda12Every 0.2s: cat /proc/mdstat

Tue Nov 30 13:46:10 2010Personalities : [raid6] [raid5] [raid4]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=maxEvery 0.2s: cat /proc/mdstat

Tue Nov 30 13:47:46 2010Personalities : [raid6] [raid5] [raid4]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[root@node1 ~]# vgdisplay vgraid | grep -i size VG Size 1.87 GB PE Size 4.00 MB Alloc PE / Size 479 / 1.87 GB Free PE / Size 0 / 0


[root@node1 ~]# vgdisplay vgraid | grep -i size 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.table0 30 linear /dev/sda 030 40 linear /dev/sdb 070 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 tableVolGroup00-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 vg0total 0brw-rw---- 1 root disk 253, 0 Mar 21 12:28 vg0-originalbrw-rw---- 1 root disk 253, 2 Mar 21 12:28 vg0-original-realbrw-rw---- 1 root disk 253, 1 Mar 21 12:28 vg0-snapbrw-rw---- 1 root disk 253, 3 Mar 21 12:28 vg0-snap-cow # dmsetup table | grep vg0 | sortvg0-original: 0 1024000 snapshot-origin 253:2vg0-original-real: 0 1024000 linear 8:17 384vg0-snap: 0 1024000 snapshot 253:2 253:3 P 16vg0-snap-cow: 0 204800 linear 8:17 1024384 # dmsetup ls --treevg0-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 PRIORIDADLos 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/sdbround-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 MULTIPATHA 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/scsiAttached devices:Host: scsi0 Channel: 00 Id: 00 Lun: 00

Vendor: SEAGATE Model: ST318305LC Rev: 2203Type: Direct-Access ANSI SCSI

revision: 03Host: scsi1 Channel: 00 Id: 00 Lun: 00

Vendor: ATA Model: ST340014AS Rev: 8.05Type: Direct-Access ANSI SCSI

revision: 05Host: scsi3 Channel: 00 Id: 00 Lun: 08

Vendor: IET Model: VIRTUAL-DISK Rev: 0Type: Direct-Access ANSI SCSI

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_lipecho "- - -" > /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 MultipathLas 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.confnode.session.timeo.replacement_timeout = 10node.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 iqn.2010-11.com.example.cluster9:iscsi> backing-store /dev/vol0/iscsi initiator-address 172.17.109.1 initiator-address 172.17.109.2 initiator-address 172.17.109.3 initiator-address 172.17.209.1 initiator-address 172.17.209.2 initiator-address 172.17.209.3</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[root@node1 ~]# iscsiadm -m discovery -t sendtargets -p 172.17.109.254172.17.109.254:3260,1 iqn.2010-11.com.example.cluster9:iscsi[root@node1 ~]# iscsiadm -m node -T iqn.2010-11.com.example.cluster9:iscsi -p 172.17.109.254 -lLogging 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

Ver que se han creado discos para estos targets:[root@node1 ~]# fdisk -lDisk /dev/sda: 5368 MB, 5368709120 bytes166 heads, 62 sectors/track, 1018 cylindersUnits = cylinders of 10292 * 512 = 5269504 bytes Device Boot Start End Blocks Id System/dev/sda1 1 191 982855 fd Linux raid autodetect/dev/sda2 192 382 982886 fd Linux raid autodetect

Descubrir targets en el segundo interfaz en el nodo:[root@node1 ~]# iscsiadm -m discovery -t sendtargets -p 172.17.209.254172.17.209.254:3260,1 iqn.2010-11.com.example.cluster9:iscsi[root@node1 ~]# iscsiadm -m node -T iqn.2010-11.com.example.cluster9:iscsi -p 172.17.209.254 -lLogging in to [iface: default, target: iqn.2010-11.com.example.cluster9:iscsi, portal: 172.17.209.254,3260]Login to [iface: default, target: iqn.2010-11.com.example.cluster9:iscsi, portal: 172.17.209.254,3260]: successful

Ver que se han creado discos para estos targets:[root@node1 ~]# fdisk -lDisk /dev/sdb: 5368 MB, 5368709120 bytes166 heads, 62 sectors/track, 1018 cylindersUnits = cylinders of 10292 * 512 = 5269504 bytes


Device Boot Start End Blocks Id System/dev/sdb1 1 191 982855 fd Linux raid autodetect/dev/sdb2 192 382 982886 fd Linux raid autodetect

Podemos comprobar que son el mismo disco, en realidad:[root@node1 ~]# /sbin/scsi_id -g -u -s /block/sdaS_beaf11[root@node1 ~]# /sbin/scsi_id -g -u -s /block/sdbS_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.confdefaults { 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 0dm_multipath 24909 1 dm_round_robinscsi_dh 11713 1 dm_multipathdm_raid45 67273 0dm_message 6977 1 dm_raid45dm_region_hash 15809 1 dm_raid45dm_mem_cache 9921 1 dm_raid45dm_snapshot 23013 0dm_zero 6209 0dm_mirror 24521 0dm_log 14657 3 dm_raid45,dm_region_hash,dm_mirrordm_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 startVemos los cambios[root@node1 ~]# fdisk -l Device Boot Start End Blocks Id System/dev/dm-1p1 1 191 982855 fd Linux raid autodetect


/dev/dm-1p2 192 382 982886 fd Linux raid autodetect[root@node1 ~]# multipath -llmpath0 (S_beaf11) dm-1 IET,VIRTUAL-DISK[size=5.0G][features=0][hwhandler=0][rw]\_ round-robin 0 [prio=0][active] \_ 0:0:0:1 sda 8:0 [active][ready]\_ round-robin 0 [prio=0][enabled] \_ 1:0:0:1 sdb 8:16 [active][ready]

Probamos los dispositivos para asegurarnos que sobreviven a un failoverHe 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/passwdroot:x:0:0:root:/root:/bin/bashbin:x:1:1:bin:/bin:/sbin/nologindaemon:x:2:2:daemon:/sbin:/sbin/nologinadm:x:3:4:adm:/var/adm:/sbin/nologin[...][root@node1 ~]# echo "HELLO" >> /mnt/data/hola[root@node1 ~]# cat /mnt/data/holaHELLO[root@node1 ~]# multipath -llsdb: checker msg is "readsector0 checker reports path is down"mpath0 (S_beaf11) dm-1 IET,VIRTUAL-DISK[size=5.0G][features=0][hwhandler=0][rw]\_ round-robin 0 [prio=0][active] \_ 0:0:0:1 sda 8:0 [active][ready]\_ round-robin 0 [prio=0][enabled] \_ 1:0:0:1 sdb 8:16 [failed][faulty][root@node1 ~]# ifup eth3[root@node1 ~]# multipath -llmpath0 (S_beaf11) dm-1 IET,VIRTUAL-DISK[size=5.0G][features=0][hwhandler=0][rw]\_ round-robin 0 [prio=0][active] \_ 0:0:0:1 sda 8:0 [active][ready]\_ round-robin 0 [prio=0][enabled] \_ 1:0:0:1 sdb 8:16 [active][ready]

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 TheHead"), es una analogía para parar rápida y completamente un nodo errante.

• Fabric fencingFibre 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_scsifence_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 fencingfence_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 statusVersion: 6.2.0Config Version: 7Cluster Name: cluster9Cluster Id: 26785Cluster Member: YesCluster Generation: 8Membership state: Cluster-MemberNodes: 2Expected votes: 1Total votes: 2Quorum: 1 Active subsystems: 9Flags: 2node DirtyPorts Bound: 0 11 177 Node name: node1.cluster9.example.comNode ID: 2Multicast addresses: 239.192.104.10Node 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 votes8 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 lsnodeCluster name: test1, config_version: 19Nodename Votes Nodeid Fencetypenode2.cluster-1.example.com 1 1 apc1node1.cluster-1.example.com 1 2 apc1node3.cluster-1.example.com 1 3 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.conf2. 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.confConfig file updated from version 2 to 3Update 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 version6.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 grupoclusvcadm -e <group>: Deshabilita un grupoclusvcadm -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 clusterThis 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 initInitializing the luci serverCreating 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[root@node2 ~]# chkconfig ricci on[root@node2 ~]# service ricci start


Creamos los nodos declusterrrs node1 y node2[root@node1 ~]# more /etc/hosts172.17.9.1 node1.cluster9.example.com node1172.17.9.2 node2.cluster9.example.com node2172.17.9.3 node3.cluster9.example.com node3

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]# lscluster.conf fence_xvm.key[root@node1 ~]# cd /etc/cluster/[root@node1 cluster]# lscluster.conf fence_xvm.key[root@node2 ~]# cd /etc/cluster/[root@node2 cluster]# lscluster.conf fence_xvm.key

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[root@node3 ~]# service ricci start[root@node3 ~]# chkconfig ricci on

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.keyCambiar el servicio webby al nodo 3 (luci) y comprobarlo en linea de comandos[root@node2 cluster]# clustat -i 1Cluster Status for cluster9 @ Wed Dec 1 14:56:59 2010Member Status: Quorate Member Name ID Status ------ ---- ---- ------ node2.cluster9.example.com 1 Online, rgmanager node1.cluster9.example.com 2 Online, rgmanager node3.cluster9.example.com 3 Online, Local, rgmanager Service Name Owner (Last)

State ------- ---- ----- ------

----- service:webby (node2.cluster9.example.com)

failed [...]


Service Name Owner (Last) 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.comTrying to relocate service:webby to node3.cluster9.example.com...Successservice:webby is now running on node3.cluster9.example.com

Vemos el estado actual de los votos[root@node2 cluster]# cman_tool statusNodes: 3Expected votes: 3Total votes: 3Quorum: 2

Paramos uno de los nodos para ver cómo obtiene quorum el cluster[root@node3 ~]# poweroff -f[root@node2 cluster]# clustat -i 1 Service Name Owner (Last)

State ------- ---- ----- ------

----- service:webby node1.cluster9.example.com

started

Al parar el nodo 2, el cluster se para también[root@node2 cluster]# clustat -i 1Message 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: <quorumd interval="1" tko="10" votes="1" label="testing"> <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" ... /><clusternode name="node2" votes="1" ... />

</clusternodes><quorumd interval="1" tko="10" votes="1" label="testing">

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

<clusternode name="node1" votes="1" ... /><clusternode name="node2" votes="1" ... /><clusternode name="node3" votes="1" ... />

</clusternodes><quorumd interval="1" tko="10" votes="3" label="testing">

<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 seconsidere 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 statusVersion: 6.2.0Config Version: 18Cluster Name: cluster9Cluster Id: 26785Cluster Member: YesCluster Generation: 124Membership state: Cluster-MemberNodes: 2Expected votes: 1Total votes: 2Quorum: 2


Active subsystems: 9Flags: 2node DirtyPorts Bound: 0 11 177 Node name: node1.cluster9.example.comNode ID: 2Multicast addresses: 239.192.104.10Node 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 mydiskmkqdisk v0.6.0Writing new quorum disk label 'mydisk' to /dev/sda3.WARNING: About to destroy all data on /dev/sda3; proceed [N/y] ? yInitializing status block for node 1...Initializing status block for node 2...Initializing status block for node 3...Initializing status block for node 4...Initializing status block for node 5...Initializing status block for node 6...Initializing status block for node 7...Initializing status block for node 8...Initializing status block for node 9...Initializing status block for node 10...Initializing status block for node 11...Initializing status block for node 12...Initializing status block for node 13...Initializing status block for node 14...Initializing status block for node 15...Initializing status block for node 16...

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 bytes166 heads, 62 sectors/track, 1018 cylindersUnits = cylinders of 10292 * 512 = 5269504 bytes Device Boot Start End Blocks Id System/dev/dm-1p1 1 191 982855 fd Linux raid autodetect/dev/dm-1p2 192 382 982886 fd Linux raid autodetect/dev/dm-1p3 383 385 15438 83 Linux

Vemos los dispositios de multipath[root@c9n1 ~]# multipath -lmpath0 (S_beaf11) dm-1 IET,VIRTUAL-DISK[size=5.0G][features=0][hwhandler=0][rw]\_ round-robin 0 [prio=0][active] \_ 1:0:0:1 sda 8:0 [active][undef]\_ round-robin 0 [prio=0][enabled] \_ 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/partitionsmajor 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[root@c9n1 ~]# multipath -l

Volvemos a descubrir todos los dispositivos de multipath existentes[root@c9n1 ~]# multipathcreate: 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]\_ round-robin 0 [prio=0][undef] \_ 0:0:0:1 sdb 8:16 [undef][ready][root@c9n1 ~]# multipath -lmpath0 (S_beaf11) dm-1 IET,VIRTUAL-DISK[size=5.0G][features=0][hwhandler=0][rw]\_ round-robin 0 [prio=0][active] \_ 1:0:0:1 sda 8:0 [active][undef]\_ round-robin 0 [prio=0][enabled] \_ 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[root@c9n1 ~]# mkqdisk -Lmkqdisk 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: 2Votes: 1TKO: 10Minimum Score: 1Device: /dev/sdaNLabel: myqdiskHeuristicsPath to Program: ping -c1 -t1 172.17.X.254Interval: 2Score: 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 20Update 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[root@c9n2 ~]# mkqdisk -Lmkqdisk v0.6.0[root@c9n2 ~]# multipath -l[root@c9n2 ~]# multipath[root@c9n2 ~]# fdisk -lDisk /dev/hda: 8589 MB, 8589934592 bytes255 heads, 63 sectors/track, 1044 cylindersUnits = cylinders of 16065 * 512 = 8225280 bytes Device Boot Start End Blocks Id System/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 nodeiscsiadm: no records found![root@c9n2 ~]# iscsiadm -m discovery -t sendtargets -p 172.17.109.254172.17.109.254:3260,1 iqn.2010-11.com.example.cluster9:iscsi[root@c9n2 ~]# iscsiadm -m discovery -t sendtargets -p 172.17.209.254172.17.209.254:3260,1 iqn.2010-11.com.example.cluster9:iscsi[root@c9n2 ~]# service iscsi restartSetting up iSCSI targets: Logging in to [iface: default, target: iqn.2010-11.com.example.cluster9:iscsi, portal: 172.17.209.254,3260]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.209.254,3260]: successfulLogin to [iface: default, target: iqn.2010-11.com.example.cluster9:iscsi, portal: 172.17.109.254,3260]: successful[root@c9n2 ~]# fdisk -l[...]Disk /dev/sda: 5368 MB, 5368709120 bytes166 heads, 62 sectors/track, 1018 cylindersUnits = cylinders of 10292 * 512 = 5269504 bytes Device Boot Start End Blocks Id System/dev/sda1 1 191 982855 fd Linux raid autodetect/dev/sda2 192 382 982886 fd Linux raid autodetect/dev/sda3 383 385 15438 83 LinuxDisk /dev/sdb: 5368 MB, 5368709120 bytes166 heads, 62 sectors/track, 1018 cylindersUnits = cylinders of 10292 * 512 = 5269504 bytes Device Boot Start End Blocks Id System/dev/sdb1 1 191 982855 fd Linux raid autodetect/dev/sdb2 192 382 982886 fd Linux raid autodetect/dev/sdb3 383 385 15438 83 Linux

Quitar de la blacklist los dispositivos comentandolos[root@c9n2 ~]# vi /etc/multipath.conf[root@c9n2 ~]# multipathcreate: mpath0 (S_beaf11) IET,VIRTUAL-DISK[size=5.0G][features=0][hwhandler=0][n/a]


\_ round-robin 0 [prio=1][undef] \_ 0:0:0:1 sda 8:0 [undef][ready]\_ round-robin 0 [prio=1][undef] \_ 1:0:0:1 sdb 8:16 [undef][ready][root@c9n2 ~]# mkqdisk -Lmkqdisk 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 onAhora vemos el estado del cluster[root@c9n1 ~]# clustat -i 1Cluster Status for cluster9 @ Thu Dec 2 11:44:30 2010Member Status: Quorate Member Name ID Status ------ ---- ---- ------ node2.cluster9.example.com 1 Online, rgmanager node1.cluster9.example.com 2 Online, Local, rgmanager node3.cluster9.example.com 3 Offline, Estranged /dev/dm-4 0 Online, Quorum Disk Service Name Owner (Last)

State ------- ---- ----- ------

----- service:webby

node2.cluster9.example.com started [root@c9n1 ~]# cman_tool statusNodes: 2Expected votes: 3Quorum device votes: 1Total votes: 3Quorum: 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, ocon 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 servicestype level name id statefence 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ísticasRequiere 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 inicialLa 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 onSi el demonio clvmd no se ha iniciado, puede ejecutar un comando service ... start en el servicio clvmd, así: # service clvmd start


apuntes rh436

Documents