# rm-rf.es | Administración de sistemas

Bitácora personal de un SysAdmin Gnu/Linux, Windows, BSD...

DM-Multipath en RedHat y CentOS


Hoy vamos a ver una introducción y la forma de activar Multipath en RedHat y derivados (CentOS, Scientific Linux…). Si todo va bien, y la cabina que nos sirve los discos está soportada por defecto por DM-Multipath es probable que no necesitemos apenas configuraciones manuales. Básicamente, el multipath lo que hace es ofrecer tolerancia a fallos y alta disponibilidad, ofreciendo más de un camino entre el sistema y los discos servidos por una SAN. Por ejemplo, cuando la conexión se hace a través de dos o más puertos Fiber Channel o cuando un disco SCSI está conectado a dos controladoras distintas.

Instalación y configuración inicial de DM-Multipath

Lo primero realizamos la instalación a través de yum:

# yum install device-mapper-multipath

Activamos su inicio automático:

# chkconfig multipathd on

mpathconf nos permite realizar una primera configuración del servicio, creando el fichero de configuración, ya sea con los valores por defecto o especificando unas directivas concretas. Para crear una configuración estándar:

# mpathconf --enable

Este otro ejemplo arrancaría dm-multipath con una configuración de failover estándar y activa el fichero de configuración:

# mpathconf --enable --with_multipathd y

Revisad la página man de mpathconf para más información. Posteriormente ya deberíamos tener el demonio de multipath. Para arrancar, parar y demás podéis usar el script de init.d como cualquier otro servicio.

# ps aux | grep multipath
root     17284  1.0  0.0 493756  4432 ?        SLl  04:24   0:00 /sbin/multipathd

Algo importante a tener en cuenta es la necesidad de incluir como “blacklist” los discos locales en el fichero de configuración. Si por ejemplo son los sdaX añadimos “sda” a la sección blacklist. De este modo multipath ignorará estos discos y no buscará más de un camino para ellos:

blacklist {
       wwid 26353900f02796769
	devnode "^(ram|raw|loop|fd|md|dm-|sr|scd|sda|st)[0-9]*"
	devnode "^hd[a-z]"
}

El fichero de configuración es lo suficientemente descriptivo para que podáis revisar cada una de las opciones.

Administración y monitorización de DM-Multipath

Si las LUN o discos que queremos tener en multipath se ven con un fdisk, el mapeo debería haberse configurado automáticamente como /dev/mapper/mpathb, /dev/mapper/mpathc…, sino, antes hay que revisar porqué el sistema no visualiza los discos. Si no se trata de controladoras o cabinas conocidas o soportadas, es probable que haya que realizar alguna configuración manual, en la mayoría de los casos el mapping debería ser automático.

La mejor forma de ver el estado del multipath es entrando en la “shell” de multipath, lo hacemos del siguiente modo:

# multipathd -k
multipathd>

Una vez dentro, algunos de los comandos más útiles son los siguientes:

Ver el estado de los path:

multipathd> show multipaths status
name   failback  queueing paths dm-st  write_prot
mpathb immediate -        4     active rw

Ver todos los multipath disponibles y mappings. En este caso hay dos mappings, cada uno con cuatro caminos:

multipathd> show multipaths
name   sysfs uuid
mpathb dm-0  360a98000572d4275525a693862534571
mpathc dm-1  360a98000572d4275525a693875677278
multipathd> show maps
name   sysfs uuid
mpathb dm-0  360a98000572d4275525a693862534571
mpathc dm-1  360a98000572d4275525a693875677278

Ver todos los path:

multipathd> show paths
hcil    dev dev_t pri dm_st  chk_st dev_st  next_check
1:0:0:0 sdb 8:16  4   active ready  running XXXXXXXXXX 20/20
1:0:0:1 sdc 8:32  4   active ready  running XXXXXXXXXX 20/20
2:0:0:0 sdd 8:48  4   active ready  running XXXXXXXXX. 19/20
2:0:0:1 sde 8:64  4   active ready  running .......... 1/20
2:0:1:0 sdf 8:80  1   active ready  running XXXXXXXXX. 18/20
2:0:1:1 sdg 8:96  1   active ready  running XXXXXXXXXX 20/20
1:0:1:0 sdh 8:112 1   active ready  running XXXXXXXXX. 18/20
1:0:1:1 sdi 8:128 1   active ready  running XXXXXXXXX. 19/20

Ver la topología y políticas configuradas para cada multipath. En este caso vemos dos LUN de fibra de 300G servidas por una cabina de discos NetAPP, con política round-robin 0 y todos sus path activos:

multipathd>  show topology
mpathb (360a98000572d4275525a693862534571) dm-0 NETAPP,LUN
size=301G features='1 queue_if_no_path' hwhandler='0' wp=rw
|-+- policy='round-robin 0' prio=4 status=active
| |- 1:0:0:0 sdb 8:16  active ready running
| `- 2:0:0:0 sdd 8:48  active ready running
`-+- policy='round-robin 0' prio=1 status=enabled
  |- 2:0:1:0 sdf 8:80  active ready running
  `- 1:0:1:0 sdh 8:112 active ready running
mpathc (360a98000572d4275525a693875677278) dm-1 NETAPP,LUN
size=301G features='1 queue_if_no_path' hwhandler='0' wp=rw
|-+- policy='round-robin 0' prio=4 status=active
| |- 1:0:0:1 sdc 8:32  active ready running
| `- 2:0:0:1 sde 8:64  active ready running
`-+- policy='round-robin 0' prio=1 status=enabled
  |- 2:0:1:1 sdg 8:96  active ready running
  `- 1:0:1:1 sdi 8:128 active ready running

Si escribís help dentro de esta shell veréis todos los comandos disponibles, podemos gestionar completamente el multipath desde aquí. Podemos suspender un camino, ponerlo en estado ‘fail’, eliminarlo, etc:

multipathd> help
multipath-tools v0.4.9 (04/04, 2009)
CLI commands reference:
 list|show paths
 list|show paths format $format
 list|show status
 list|show daemon
 list|show maps|multipaths
 list|show maps|multipaths status
 list|show maps|multipaths stats
 list|show maps|multipaths format $format
 list|show maps|multipaths topology
 list|show topology
 list|show map|multipath $map topology
 list|show config
 list|show blacklist
 list|show devices
 list|show wildcards
 add path $path
 remove|del path $path
 add map|multipath $map
 remove|del map|multipath $map
 switch|switchgroup map|multipath $map group $group
 reconfigure
 suspend map|multipath $map
 resume map|multipath $map
 resize map|multipath $map
 disablequeueing map|multipath $map
 restorequeueing map|multipath $map
 disablequeueing maps|multipaths
 restorequeueing maps|multipaths
 reinstate path $path
 fail path $path
 paths count
 quit|exit

Esto ha sido una mera introducción, para profundizar en el tema, os recomiendo la lectura de los siguientes artículos. Próximamente veremos como configurar desde 0 una LUN FC servida NetAPP en Multipath y asignarle un filesystem.

Bonding/Teaming/Trunking en RHEL y CentOS


bonding linux

El Bonding (también conocido como teaming, y en switching como trunking) es, básicamente, la unión de varias interfaces de red para que trabajen como una única interfaz lógica. Esta configuración permite establecer configuraciones de activo-pasivo, balanceo de carga o crear un agregado de interfaces con un ancho de banda que supone la suma del de todas las interfaces asignadas.

Antes de comenzar la configuración, nos aseguramos de tener cargado el módulo bonding:

# lsmod | grep bonding
bonding               109558  0
ipv6                  264641  29 bonding,ip6t_REJECT,nf_conntrack_ipv6,nf_defrag_ipv6,cnic

En caso de no estar lo cargamos:

# modprobe bonding

Tenemos que configurar unos parámetros de kernel para añadir esta nueva interfaz/funcionalidad:

# vi /etc/modprobe.conf
alias bond0 bonding
options bond0 mode=6 miimon=100

El valor mode, especificado en 6 indica que el tipo de bonding va a ser de balanceo de carga. Los posibles valores son de 0 a 6:

  • 0: round robin policy, defecto
  • 1: active backup policy
  • 2: XOR
  • 3: brodcast
  • 4: 802.3ad
  • 5:  balance-tlb
  • 6:  balance-alb

El valor miimon indica con un valor entero la frecuencia de monitorización del link. Para conocer todos estos parámetros en condiciones os recomiendo revisar la documentación del kernel sobre bonding

Ahora vamos a crear el fichero de configuración para la interfaz Bond0, que será la que en nuestro caso creará el bonding de eth0 y eth1. El fichero de configuración se crea en la misma ruta que el resto /etc/sysconfig/network-scripts/ifcfg-XXX. Este fichero es el que contendrá la configuración IP, NETMASK, etc.

# vim /etc/sysconfig/network-scripts/ifcfg-bond0
DEVICE=bond0
ONBOOT=yes
IPADDR=192.168.1.190
NETMASK=255.255.255.0
BROADCAST=192.168.1.255
NETWORK=192.168.1.0
USERCTL=no
BOOTPROTO=none

Ahora configuramos eth0 y eth1, en ellas no establecemos ninguna configuración IP, sino que especificamos que es una interfaz esclavo (slave) y que su master es bond0:

vi /etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE=eth0
ONBOOT=yes
USERCTL=no
BOOTPROTO=none
MASTER=bond0
SLAVE=yes
vi /etc/sysconfig/network-scripts/ifcfg-eth1
DEVICE=eth1
ONBOOT=yes
USERCTL=no
BOOTPROTO=none
MASTER=bond0
SLAVE=yes

Una vez configurado, reiniciamos el servicio de red:

# /etc/init.d/network restart

Si todo ha ido bien ya veremos la interfaz bond0 en ifconfig:

# ifconfig
bond0     Link encap:Ethernet  HWaddr 08:00:27:00:C8:7A
          inet addr:192.168.1.190  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addr: fe80::a00:27ff:fe00:c87a/64 Scope:Link
          UP BROADCAST RUNNING MASTER MULTICAST  MTU:1500  Metric:1
          RX packets:1029 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1198 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:101972 (99.5 KiB)  TX bytes:182347 (178.0 KiB)

eth0      Link encap:Ethernet  HWaddr 08:00:27:00:C8:7A
          UP BROADCAST RUNNING SLAVE MULTICAST  MTU:1500  Metric:1
          RX packets:946 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1144 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:90003 (87.8 KiB)  TX bytes:175136 (171.0 KiB)
          Interrupt:11 Base address:0xc020 

eth1      Link encap:Ethernet  HWaddr 08:00:27:00:C8:7A
          UP BROADCAST RUNNING SLAVE MULTICAST  MTU:1500  Metric:1
          RX packets:94 errors:0 dropped:0 overruns:0 frame:0
          TX packets:59 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:12695 (12.3 KiB)  TX bytes:8325 (8.1 KiB)
          Interrupt:10 Base address:0xc060 

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:1241 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1241 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:170253 (166.2 KiB)  TX bytes:170253 (166.2 KiB)

Podemos monitorizar el estado del bonding desde /proc/net/bonding/bond0:

# cat /proc/net/bonding/bond0
Ethernet Channel Bonding Driver: v3.6.0 (September 26, 2009)

Bonding Mode: load balancing (round-robin)
MII Status: up
MII Polling Interval (ms): 0
Up Delay (ms): 0
Down Delay (ms): 0

Slave Interface: eth0
MII Status: up
Speed: 100 Mbps
Duplex: full
Link Failure Count: 0
Permanent HW addr: 08:00:27:00:c8:7a
Slave queue ID: 0

Slave Interface: eth1
MII Status: up
Speed: 100 Mbps
Duplex: full
Link Failure Count: 0
Permanent HW addr: 08:00:27:fd:48:08
Slave queue ID: 0

SELinux ‘semanage: command not found’


semanage (SELinux Policy Management tool) es un comando que permite configurar políticas de SELinux en RHEL, CentOS, etc. Lo más probable es que en un sistema Red Hat 6 instalado por defecto (base) el comando no se encuentre disponible:

# semanage login -l
semanage: command not found

Si visteis el artículo que hice hace un tiempo sobre trucos de yum recordaréis que con “whatprovides” podemos encontrar rápidamente el paquete que contiene un determinado binario/fichero:

# yum whatprovides */semanage
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
 * base: sunsite.rediris.es
 * extras: sunsite.rediris.es
 * updates: sunsite.rediris.es
libsemanage-devel-2.0.43-4.el6.i686 : Header files and libraries used to build
                                    : policy manipulation tools
Repo        : base
Matched from:
Filename    : /usr/include/semanage

policycoreutils-python-2.0.83-19.1.el6.i686 : SELinux policy core python
                                            : utilities
Repo        : base
Matched from:
Filename    : /usr/sbin/semanage

policycoreutils-python-2.0.83-19.8.el6_0.i686 : SELinux policy core python
                                              : utilities
Repo        : updates
Matched from:
Filename    : /usr/sbin/semanage

Así que instalamos el paquete (y sus dependencias) y listo:

# yum install policycoreutils-python-2.0.83-19.1.el6.i686
# semanage login -l

Login Name         SELinux User           MLS/MCS Range            

__default__               unconfined_u              s0-s0:c0.c1023
root                      unconfined_u              s0-s0:c0.c1023
system_u                  system_u                  s0-s0:c0.c1023

RHEL/CentOS 6: adios System V, hola Upstart


Uno de los cambios importantes que hemos encontrado con la salida de Red Hat Enterprise Linux 6 y por consiguiente CentOS 6 es el cambio del sistema de arranque de los servicios. El nuevo sistema tiene por nombre Upstart y reemplaza al que nos acompañó durante muchos años, System V.

Una de las principales diferencias entre System V y Upstart es que el primero trabaja de forma sincrona mientras que Upstart lo hace de forma asíncrona, es decir, no arranca/para un servicio después de otro sino que puede hacerlo en paralelo. Esto implica un aumento considerable de la velocidad de arranque y evita que un servicio tenga esperar a que otro termine para poder arrancar. Otra característica interesante de Upstart es que tiene la capacidad de supervisar los servicios mientras el sistema está funcionando. Upstart también es compatible con los scripts de arranque del sistema System V por lo cual la migración de un sistema a otro es más sencilla.

Los scripts de arranque basados en System V seguirán emplazados en /etc/init.d, mientras que los basados en Upstart debemos añadirlos en /etc/init/*.conf. Podemos ver un ejemplo de la sintaxis utilizada revisando cualquiera de los que ahí se encuentran. De momento podréis ver que únicamente hay scripts propios de sistema, los servicios siguen teniendo sus scripts de arranque en init.d. Vamos a crear un script sencillo para que veáis su funcionamiento. Básicamente queremos que un script propio de prueba esté siempre corriendo, que arranque en el runlevel 3 y que si cae se levante de forma automática:

vim /etc/init/test.conf

#
# Este servicio arranca y monitoriza nuestro script test.sh.
start on runlevel 3

respawn
respawn limit 15 5
exec sh /root/test.sh

Mediante “respawn” especificamos que en caso de que el servicio termine de forma inesperada, Upstart intente levantarlo. Después, con “respawn limit” especificamos el número de intentos y durante cuanto tiempo. En caso de pasar ese tiempo/número de intentos dejaría de intentarlo y el servicio quedaría detenido.

Arrancamos el servicio con el comando initctl:

# initctl start test
test start/running, process 1581

Si matamos el script, veremos en el log /var/log/messages como automáticamente lo levanta. En caso de tener 10 intentos fallidos durante 5 segundos (especificado en el script) dejaría de intentarlo y el script quedaría parado:

# kill 1581
# tail -2 /var/log/messages
Oct 30 19:18:45 server1 init: test main process (1581) killed by TERM signal
Oct 30 19:18:45 server1 init: test main process ended, respawning

Podéis encontrar más información sobre initctl en la salida de ayuda del propio comando, páginas man, etc. También de init:

# initctl help
Job commands:
  start                       Start job.
  stop                        Stop job.
  restart                     Restart job.
  reload                      Send HUP signal to job.
  status                      Query status of job.
  list                        List known jobs.

Event commands:
  emit                        Emit an event.

Other commands:
  reload-configuration        Reload the configuration of the init daemon.
  version                     Request the version of the init daemon.
  log-priority                Change the minimum priority of log messages from the init daemon
  help                        display list of commands

For more information on a command, try `initctl COMMAND --help'.
# man init
# man initctl

¿Cómo arrancar en modo emergencia en RHEL 6 / CentOS 6?


Existen una serie de runlevels que nos permiten arrancar un sistema Linux con distintas características según nuestras necesidades. En el anterior enlace los tenéis detallados. En anteriores versiones de RHEL, CentOS y derivados cuando necesitábamos acceder al sistema en modo emergencia (sin necesidad de especificar la clave de root y sin los sistemas de ficheros montados en modo RW) añadíamos a la línea de arranque que se le pasa al kernel en el grub el parámetro emergency. Este parámetro ya no se usa y se ha pasado a utilizar dos variantes.

En primer lugar, hay que decir que para acceder cambiando el runlevel hay que añadir a la línea de comando que se pasa al kernel el número del runlevel. Para ello, en el grub presionamos la letra a y añadimos el número del runlevel:

RHEL-grub

Presionamos ‘a’ para añadir un parámetro nuevo a la línea y ya podemos añadir el runlevel deseado.

RHEL-grub2

Para RHEL 6, CentOS6 y derivados, en lugar de emergency tenemos dos opciones para entrar en modo emergencia:

  • single: Modo single user, el arranque será como el runlevel 1 pero sin ejecutar los scripts de arranque en /etc/rc1.d
  • init=/bin/sh: Este sería el equivalente al modo emergencia, no ejecuta ningún script de arranque e únicamente monta la partición raíz (/) en modo lectura.

Si queremos ver el proceso de arranque, podemos quitar de la línea las palabras rhgb quiet (arranque gráfico). Para entrar en modo emergencia quedaría una línea como la de la siguiente imagen. Presionamos ENTER y arrancará el sistema:

Emergency mode RHEL 6

ACL (Access Control List) en sistemas de ficheros GNU/Linux


Para un usuario medio de GNU/Linux e incluso para la mayoría de usuarios avanzados, las posibilidades que nos ofrecen el sistema de permisos y propietario estándar es más que suficiente. No obstante, conviene conocer el sistema de listas de control de acceso, conocido comúnmente como ACL (Access Control List) que nos permite extender estos permisos a nivel de ficheros y directorios.

Estas ACL permiten definir permisos concretos para un determinado usuario o grupo en ficheros y directorios, además, se asignan igual que los permisos estándar, con formato octal o simbólico (rwx). Básicamente, en caso de tener un fichero o directorio con unos permisos concretos determinados para su propietario y grupo, nos permite añadir usuarios o grupos extra con unos permisos completamente independientes a los definidos con los permisos estándar.

Activar ACL en el sistema de ficheros

Verificamos con el comando tune2fs si el sistema de ficheros sobre el que queremos tener ACL tiene activado ACL:

# tune2fs -l /dev/mapper/VolGroup00-LogVol00 | grep acl
Default mount options:    user_xattr acl

En caso de no aparecer la opción, tendríamos que remontar el filesystem añadiendo la flag, para hacerlo persistente habría que añadirla en el /etc/fstab.

[root@cluster01 ~]# mount -o remount,acl /
# mount
/dev/mapper/VolGroup00-LogVol00 on / type ext3 (rw,acl)

Ver y cambiar las ACL en ficheros/directorios

Para listar los permisos genéricos de un fichero o directorio y las ACL utilizamos el comando getfacl

# getfacl prueba.tmp
# file: prueba.tmp
# owner: root
# group: root
user::rw-
group::r--
other::r--

El fichero prueba.tmp no tiene ACL establecidas, sólo vemos los permisos estándar. Para comenzar a añadir permisos de ACL utilizamos el comando setfacl. En la página man encontramos información relativa a la sintaxis y formato para el cambio de permisos en usuarios y grupos, máscara y otros:

      [d[efault]:] [u[ser]:]uid [:perms]
              Permissions of a named user. Permissions of the file owner if uid is empty.

       [d[efault]:] g[roup]:gid [:perms]
              Permissions of a named group. Permissions of the owning group if gid is empty.

       [d[efault]:] m[ask][:] [:perms]
              Effective rights mask

       [d[efault]:] o[ther][:] [:perms]
              Permissions of others.

Vamos a ver algún ejemplo. En este primer caso vamos a asignar permiso total (777) al usuario foo contra el fichero anterior, del cual es propietario root.

# setfacl -m u:foo:7 prueba.tmp

Y ahí lo tenemos, con sus permisos especiales asignados con ACL:

# getfacl prueba.tmp 
# file: prueba.tmp
# owner: root
# group: root
user::rw-
user:foo:rwx
group::r--
mask::rwx
other::r--

También los podemos asignar con notación simbólica en lugar de octal, vamos a cambiarlo a únicamente lectura para foo:

# setfacl -m u:foo:r prueba.tmp
# getfacl prueba.tmp 
# file: prueba.tmp
# owner: root
# group: root
user::rw-
user:foo:r--
group::r--
mask::r--
other::r--

Si nos fijamos, al listar el fichero con un ls vemos que ha aparecido un ‘+’ indicando que hay ACLs asignadas:

# ll prueba.tmp
-rw-r--r--+ 1 root root 0 Sep 28 17:32 prueba.tmp

Si con el parámetro ‘-m’ cambiabamos las ACL, con ‘-x’ las borramos para un usuario concreto, y con ‘-b’ para todas las asignadas al fichero:

# setfacl -x u:foo prueba.tmp
# setfacl -b prueba.tmp

A la hora de asignar ACL para directorios, resulta interesante poder asignar unas ACL por defecto para todas aquellos subdirectorios que se vayan creando, así como los ficheros que contenga y se vayan metiendo. Vamos a asignar permiso total al usuario foo para el directorio prueba, es prácticamente igual que con ficheros pero añadiendo la ‘d’ de default:

# setfacl -m d:u:foo:rwx testdir

Nota: Sólo a los directorios se les puede añadir ACLs por defecto, si lo hacéis en ficheros:

# setfacl -m d:u:foo:rwx test
setfacl: /root/test: Only directories can have default ACLs

Si revisamos las ACL del directorio vemos asignados todos los default, podríamos también cambiarlo para el propietario, el grupo y ‘otros’ además de para los nuevos usuarios que añadamos vía ACL:

# getfacl testdir/
# file: testdir
# owner: root
# group: root
user::rwx
group::r-x
other::r-x
default:user::rwx
default:user:foo:rwx
default:group::r-x
default:mask::rwx
default:other::r-x

Espero que esta introducción a las ACL en GNU/Linux os haya sido de utilidad, es un mundo poco explorado pero lleno de posibilidades.

Cómo crear un RAID 1 por software en RHEL y CentOS


raid1Vamos a ver como crear un RAID 1 (espejo) por software entre dos discos extra añadidos a un sistema CentOS o RHEL. Este sistema nos ofrece total redundancia de datos a expensas de utilizar el doble de espacio en disco. En caso de disponer una controladora para hacer el RAID por hardware lógicamente es más recomendable que esta opción, ya que el rendimiento es mucho mejor.

Vamos a partir de la base de que además del disco que engloba el sistema, tenemos dos discos más disponibles para trabajar:

# fdisk -l | egrep -e "hdb|hdd"
Disk /dev/hdb doesn't contain a valid partition table
Disk /dev/hdd doesn't contain a valid partition table
Disk /dev/hdb: 1073 MB, 1073741824 bytes
Disk /dev/hdd: 1073 MB, 1073741824 bytes

Creación del RAID 1

Lo primero que tenemos que hacer es configurar dos particiones, una en cada disco y del tipo RAID AUTODETECT (fd). Aquellos que tengáis dudas con este paso, revisad este artículo: crear y eliminar particiones con fdisk en Linux

Haríamos este paso en ambos discos:

# fdisk /dev/hdd
Device contains neither a valid DOS partition table, nor Sun, SGI or OSF disklabel
Building a new DOS disklabel. Changes will remain in memory only,
until you decide to write them. After that, of course, the previous
content won't be recoverable.

The number of cylinders for this disk is set to 2080.
There is nothing wrong with that, but this is larger than 1024,
and could in certain setups cause problems with:
1) software that runs at boot time (e.g., old versions of LILO)
2) booting and partitioning software from other OSs
   (e.g., DOS FDISK, OS/2 FDISK)
Warning: invalid flag 0x0000 of partition table 4 will be corrected by w(rite)

Command (m for help): n
Command action
   e   extended
   p   primary partition (1-4)
p
Partition number (1-4): 1
First cylinder (1-2080, default 1):
Using default value 1
Last cylinder or +size or +sizeM or +sizeK (1-2080, default 2080):
Using default value 2080

Command (m for help): t Selected partition 1
Hex code (type L to list codes): fd
Changed system type of partition 1 to fd (Linux raid autodetect)

Command (m for help): w
The partition table has been altered!

Calling ioctl() to re-read partition table.
Syncing disks.
# partprobe

El resultado hasta el momento sería esto (omitiendo el disco de sistema):

# fdisk -l

Disk /dev/hdb: 1073 MB, 1073741824 bytes
16 heads, 63 sectors/track, 2080 cylinders
Units = cylinders of 1008 * 512 = 516096 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/hdb1               1        2080     1048288+  fd  Linux raid autodetect

Disk /dev/hdd: 1073 MB, 1073741824 bytes
16 heads, 63 sectors/track, 2080 cylinders
Units = cylinders of 1008 * 512 = 516096 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/hdd1               1        2080     1048288+  fd  Linux raid autodetect

Ahora ya podemos hacer uso del comando mdadm para crear el RAID 1 entre las particiones configuradas en ambos discos. Especificamos con -v la opción verbose, -C significa la creación del raid seguido del nombre asignado al array /dev/md0 y le indicamos que los dos discos serán activos (-n 2), podríamos asignar discos spare con -x. Finalmente especificamos los dispositivos a configurar en el array (las dos particiones creadas antes) y especificamos que es un RAID 1 con -l 1:

# mdadm -v -C /dev/md0 -n 2 /dev/hdb1 /dev/hdd1 -l 1
mdadm: size set to 1048192K
mdadm: array /dev/md0 started.

Monitorizar y gestionar el RAID

Podemos ver el estado del RAID en cualquier comento con mdadm –detail seguido del RAID a revisar:

# mdadm --detail /dev/md0
/dev/md0:
        Version : 0.90
  Creation Time : Tue Sep 27 18:02:46 2011
     Raid Level : raid1
     Array Size : 1048192 (1023.80 MiB 1073.35 MB)
  Used Dev Size : 1048192 (1023.80 MiB 1073.35 MB)
   Raid Devices : 2
  Total Devices : 2
Preferred Minor : 0
    Persistence : Superblock is persistent

    Update Time : Tue Sep 27 18:03:33 2011
          State : clean
 Active Devices : 2
Working Devices : 2
 Failed Devices : 0
  Spare Devices : 0

           UUID : 9a7817d8:038050a4:82a2f37d:414f679e
         Events : 0.2

    Number   Major   Minor   RaidDevice State
       0       3       65        0      active sync   /dev/hdb1
       1      22       65        1      active sync   /dev/hdd1

En caso de que uno de los discos fallase, habría que sacar del raid el disco fallido y reemplazarlo por otro, con el cual habría que seguir todos los pasos anteriores para prepararlo.

Forzamos el disco como fallido para hacer la prueba:

# mdadm /dev/md0 -f /dev/hdd1
mdadm: set /dev/hdd1 faulty in /dev/md0

Si ahora hicieramos un mdadm -D /dev/md0 veríamos el fallo del disco y el estado degraded:

# mdadm --detail /dev/md0
/dev/md0:
        Version : 0.90
  Creation Time : Tue Sep 27 18:02:46 2011
     Raid Level : raid1
...
...
...
          State : clean, degraded
 Number   Major   Minor   RaidDevice State
       0       3       65        0      active sync   /dev/hdb1
       1       0        0        1      removed

       2      22       65        -      faulty spare   /dev/hdd1

Sacamos el disco fallido del raid:

# mdadm /dev/md0 -r /dev/hdd1
mdadm: hot removed /dev/hdd1

Ahora el estado seguiría siendo degraded pero sin el disco fallido, así que sólo quedaría añadir un nuevo disco para que el RAID se reconstruyera:

# mdadm /dev/md0 -a /dev/hdd1
mdadm: re-added /dev/hdd1

Y automáticamente debería activarse el rebuild/recover y sincronizar la información entre ambos discos:

# mdadm -D /dev/md0
/dev/md0:
        Version : 0.90
  Creation Time : Tue Sep 27 18:02:46 2011
     Raid Level : raid1
     Array Size : 1048192 (1023.80 MiB 1073.35 MB)
  Used Dev Size : 1048192 (1023.80 MiB 1073.35 MB)
   Raid Devices : 2
  Total Devices : 2
Preferred Minor : 0
    Persistence : Superblock is persistent

    Update Time : Tue Sep 27 18:12:32 2011
          State : clean, degraded, recovering
 Active Devices : 1
Working Devices : 2
 Failed Devices : 0
  Spare Devices : 1

 Rebuild Status : 44% complete

           UUID : 9a7817d8:038050a4:82a2f37d:414f679e
         Events : 0.6

    Number   Major   Minor   RaidDevice State
       0       3       65        0      active sync   /dev/hdb1
       1      22       65        1      spare rebuilding   /dev/hdd1

Eliminar un RAID

Para eliminar un RAID antes hay que pararlo, y posteriormente destruirlo:

# mdadm -vS /dev/md0
mdadm: stopped /dev/md0
# mdadm -vr /dev/md0

A partir de aquí, pues únicamente quedaría dar formato a /dev/md0 con el sistema de ficheros que necesitéis y gestionarlo como un sistema de ficheros normal.

Esquema raid: dis.um.es

Repositorio CentOS-5.6 Continuous Release ( CR ) disponible


CentOSCentOS ha publicado un nuevo repositorio a través de mirror.centos.org. CentOS-5.6 Continuous Release ( CR ) contiene rpms que serán incluidas en la próxima versión de la rama 5.X de CentOS, pero que debido a que son actualizaciones de seguridad y soluciones a bugs conocidos es recomendable instalarlas sin tener que esperar a que salgan a la luz con la nueva versión 5.7, que saldrá aproximadamente en una semana.

Se recomienda encarecidamente activar estos repositorios y actualizar el sistema. Únicamente hay que instalar los siguientes repos y actualizar el sistema. Como ya sabéis se añadirá el nuevo repositorio CentOS-CR.repo en la ruta /etc/yum.repos.d/. Podéis descargar los rpm a continuación:

i386:

http://mirror.centos.org/centos/5.6/cr/i386/RPMS/centos-release-cr-5-6.el5.centos.1.i386.rpm

md5: 67bbeb40cb77a91379847074667d2956
sha256: 50cd9f3d35b391a9009a9caae80182dcfccfa5abaf4ff4ef5f4d880bcf26b04c

x86_64:

http://mirror.centos.org/centos/5.6/cr/x86_64/RPMS/centos-release-cr-5-6.el5.centos.1.x86_64.rpm

md5: c447f54818a657a9dfd7fdd28a28cfcc
sha256: dab390a0fca17612e438b215fc90448ebcef982e96e25cbea8426f00edc8b7a5