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

Blog de un SysAdmin Unix, Gnu/Linux, Windows y lo que haga falta.

Clustered Logical Volume Manager (CLVM) y GFS2

En esta entrada vamos a ver el proceso de instalación y configuración de CLVM y la forma de crear un sistema de ficheros GFS2. Se podría decir que esta entrada sería la continuación de aquella en la que expliqué el Multipath en Linux. Básicamente, la idea es utilizar CLVM para aprovecharnos de las ventajas de LVM (Logical Volume Manager) en un entorno de Cluster.

Como estamos trabajando en un cluster, voy a diferenciar cuando una tarea se realiza en un único nodo o en todos. Los paquetes de cluster LVM y GFS los instalaremos en todos los nodos del cluster:

# yum install lvm2-cluster.x86_64 gfs2-utils.x86_64

Posteriormente nos aseguramos de que arranquen automáticamente:

# chkconfig clvmd on
# chkconfig gfs2 on

Con la configuración por defecto, LVM no trabaja en modo Cluster, incluso aunque hayamos instalado los paquetes de clvmd o lo hayamos arrancado, debemos reconfigurarlo con el siguiente comando. Lo que hace es modificar el fichero de configuración lvm.conf y especificar el tipo de bloqueo necesario para trabajar en cluster (cluster-wide locking).

# /usr/sbin/lvmconf --enable-cluster

Arrancamos el servicio clvmd:

# service clvmd start

A partir de aquí, el proceso de gestión de volumenes es el mismo que con LVM. Revisad este otro artículo si tenéis alguna duda: gestión de LVM en Linux (Logical Volume Manager). Vamos no obstante a ver como crearíamos una nueva partición con parted en lugar de fdisk como en el otro artículo. En este caso es un disco en multipath, por eso la ruta del mapeo. Esto lo realizamos únicamente en uno de los nodos:

# parted /dev/mapper/mpatha mklabel msdos
# parted /dev/mapper/mpatha mkpart primary 64s 100%
# parted /dev/mapper/mpatha set 1 lvm on

En ese mismo nodo ya podemos crear el volumen físico y el grupo que contendrá el volumen lógico con la partición creada antes:

# pvcreate /dev/mapper/mpathap1
# vgcreate vgroup01 /dev/mapper/mpathap1

Antes de crear el volumen, podemos ir al resto de nodos y asegurarnos que ven la nueva partición y el volumen físico y grupo. Ejecutamos partprobe para refrescar la tabla de particiones en la unidad multipath y luego un rescaneo de los volúmenes de LVM:

# partprobe
# vgscan

Debería aparecer el volumen vgroup01 al ejecutar un vgdisplay, sino algo falla y CLVMD no está funcionando ya que no se propagan los cambios entre los nodos del cluster. Si todo ha ido bien, ya podemos crear (sólo en un nodo) el volumen lógico final y crear el sistema de ficheros GFS2:

# lvcreate -n logical01 -l 77063 vgroup01
# mkfs.gfs2 -p lock_dlm -t cluster01:fs_data -j 2 /dev/vgroup01/logical01

A la hora de crear el sistema de ficheros, especificamos el nombre del protocolo de bloqueo a usar, para un cluster es lock_dlm. Después se indica el nombre del cluster y  del filesystem separados por “:”, en nuestro caso el cluster (RHCS) se llama cluster01 y el fs fs_data. Tenemos que especificar el número de journals que queremos crear, tiene que haber uno por cada nodo del cluster. En este caso 2 nodos así que ponemos 2. Lo último es la ruta al volumen lógico o partición a utilizar.

A partir de aquí ya depende si queréis añadir el filesystem para que se monte automáticamente al arrancar los nodos (/etc/fstab/) o si será el cluster el encargado de gestionarlo.

Configurar Multipath I/O (MPIO) en Windows 2008 Server

El otro día vimos como activar Multipath en Linux (RedHat y derivados). Ahora vamos a ver como hacerlo en Windows 2008 Server. Resulta muy sencillo, ya que únicamente hay que activar la característica “Multipath I/O” y hacer una búsqueda de los caminos.

Añadir soporte Multipath I/O MPIO

Abrimos el Server Manager (Administrative Tools > Server Manager) y pinchamos en añadir características (Add Features) dentro de la sección Features. En el asistente, seleccionamos Multipath I/O e instalamos.

Configurar los caminos

Antes de activar Multipath, si accedemos al gestor de storage/discos en el Server Manager veremos que cada camino es detectado como un disco. Lo que nos interesa es que detecte únicamente el disco real y que por debajo gestione todos los caminos. Ahora que hemos instalado la característica, accedemos a MPIO Properties desde el panel de control o desde MPIO en Administrative Tools del menú Inicio.

Ahora, para descubrir las LUN FC debería ser suficiente con ir a la pestaña “Discover Multi-Path” y pinchar en “Add”. Solicitará un reinicio del sistema y una vez realizado los caminos y discos debería haber sido detectados.

Nota: en esta imagen ya han sido detectadas, por eso no sale disponible el botón.

Multipath Windows 2008 Server

Podéis verificar la configuración de cada mapeo con la herramienta mpclaim.exe:

PS C:\Users\Administrator> mpclaim.exe -s -d 0

MPIO Disk0: 04 Paths, Round Robin with Subset, Implicit Only
   Controlling DSM: Microsoft DSM
   SN: 60A9800572D4275525A6939686A5063
   Supported Load Balance Policies: FOO RRWS LQD WP LB

   Path ID          State              SCSI Address      Weight
   ---------------------------------------------------------------------------
   0000000077020001 Active/Unoptimized 002|000|001|000   0
     TPG_State : Active/Unoptimized, TPG_Id: 1, : 1

   0000000077020000 Active/Optimized   002|000|000|000   0
     TPG_State : Active/Optimized  , TPG_Id: 0, : 257

   0000000077010001 Active/Unoptimized 001|000|001|000   0
     TPG_State : Active/Unoptimized, TPG_Id: 1, : 2

   0000000077010000 Active/Optimized   001|000|000|000   0
     TPG_State : Active/Optimized  , TPG_Id: 0, : 258

El último número hace referencia al mapeo/disco que queremos revisar,

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.

Netapp Snapmirror entre dos cabinas

NetAppHacía ya un tiempo que no hacia entradas sobre Netapp, así que vamos a retomar un poco el tema con la utilidad Snapmirror, que permite replicar volumenes/qtrees entre filers. Snapmirror va a trabajar de forma sincrona (snapmirror_sync) y replicando los datos contra el volumen de respaldo a la vez que se escriben en el volumen original o por contra especificando una periodicidad concreta al más puro estilo cron. Los datos antes de ser escritos en disco se guardan en NVRAM con el fin de asegurar su consistencia.

Lo primero de todo, lógicamente es disponer la licencia de snapmirror en ambas cabinas, en este caso vamos a trabajar sobre netapp01 (192.168.1.100) y netapp02 (192.168.1.129). Activamos la licencia y posteriormente snapmirror:

Activación de Snapmirror

Para realizar en los dos filer:

NetApp01> license add XXXXXX
A snapmirror site license has been installed.
snapmirror enabled.
NetApp01> Sat Dec  3 20:02:32 GMT [rc:notice]: snapmirror licensed

NetApp01> license add XXXXXX
A snapmirror_sync site license has been installed.
Sync SnapMirror enabled.

NetApp01> options snapmirror.enable on
NetApp01> options snapmirror.log.enable on

Conectividad entre filers

Lo primero que debemos hacer es revisar la conectividad entre ambas cabinas:

NetApp01> ping 192.168.1.129
192.168.1.129 is alive

NetApp02> ping 192.168.1.100
192.168.1.100 is alive

Configuramos el filer origen permitiendo que el filer destino pueda acceder a él, para ello hay que añadir el hostname/ip del filer destino en el fichero /etc/snapmirror.allow. Antes de nada verificad si existe y tiene contenido para preservarlo, ya que con wrfile eliminamos lo que hubiera anteriormente:

NetApp01> rdfile /etc/snapmirror.allow
/etc/snapmirror.allow: No such file or directory

NetApp01> rdfile /etc/snapmirror.allow
/etc/snapmirror.allow: No such file or directory
NetApp01> wrfile /etc/snapmirror.allow
192.168.1.129
NetApp02
CTRL + C
read: error reading standard input: Interrupted system call
NetApp01> rdfile /etc/snapmirror.allow
192.168.1.129

Creación de volúmenes a replicar

Vamos a crear el volumen de datos en el filer origen:

NetApp01> vol create vol_backup aggr_test 200M
Creation of volume 'vol_backup' with size 200m on containing aggregate
'aggr_test' has completed.

Snapmirror

Una vez creado el volumen en el filer origen, ya podemos crear la configuración de Snapmirror en el destino. Algunas consideraciones son que para hacer Snapmirror el volumen destino tiene que estar en modo restricted. De este modo únicamente permitimos ciertas operaciones en el volumen, como snapmirror o tareas de mantenimiento, pero nunca el acceso a los datos:

Creamos el volumen:

NetApp02> vol create vol_mirror aggr0 200M
Creation of volume 'vol_mirror' with size 200m on containing aggregate
'aggr0' has completed.

Lo restringimos para poder hacer la transferencia inicial:

NetApp02> vol restrict vol_mirror
Volume 'vol_mirror' is now restricted.

Ejecutamos la transferencia inicial de datos:

NetApp02> snapmirror initialize -S 192.168.1.100:vol_backup NetApp02:vol_mirror
Transfer started.
Monitor progress with 'snapmirror status' or the snapmirror log.

Podemos ver el estado mediante snapmirror status o a través del log específico (en caso de haber sido activado como mencionaba antes):

NetApp02> snapmirror status
Snapmirror is on.
Source                    Destination           State          Lag        Status
192.168.1.100:vol_backup  NetApp02:vol_mirror   Snapmirrored   00:00:15   Idle

Configurar periodicidad de sincronización

Una vez realizada la copia inicial, podemos programar las copias incrementales cada X tiempo o que se realicen de forma síncrona. En estas copias únicamente se transferirán los bloques que hayan sido modificados desde la última realizada. Estas configuraciones se especifican en el fichero de configuración /etc/snapmirror.conf con esta estructura:

filer_origen:volumen_origen filer_destino:volumen_destino – opciones min hora dia_mes dia_sem

Para configurar que la copia sea síncrona y que los datos se mantengan actualizados al mismo tiempo en ambos volúmenes únicamente hay que añadir la palabra sync (recordad revisar antes el contenido del fichero):

NetApp02> wrfile /etc/snapmirror.conf
192.168.1.100:vol_backup NetApp02:vol_mirror - sync
CTRL+C

Nota: para la replicación síncrona el volumen tiene que tener un tamaño mínimo, sino recibiréis este error:

Sun Dec 4 08:38:00 GMT [snapmirror.src.sync.FvolSyncTooSmall:error]: The flexible volume Synchronous SnapMirror source vol_backup is 200 MB, which is smaller than the minimum supported size of 10240 MB.

Y si lo que queremos es que la sincronización se realice periódicamente en lugar de a tiempo real usamos el estilo cron que veíamos en la estructura. Vamos a configurarlo todos los días a las 23:00:

NetApp02> wrfile /etc/snapmirror.conf
192.168.1.100:vol_backup NetApp02:vol_mirror - 00 23 * *
CTRL+C

Es recomendable cuando hacemos la configuración de snapmirror y las primeras sincronizaciones tener las consolas de ambas cabinas abiertas para revisar todos los errores que puedan ir apareciendo en una y otra.

Si necesitaramos forzar manualmente la sincronización podemos hacerlo con el comando snapmirror update, con la misma sintaxis que utilizamos con la sincronización inicial:

NetApp02> snapmirror update -S 192.168.1.100:vol_backup NetApp02:vol_mirror
Transfer started.
Monitor progress with 'snapmirror status' or the snapmirror log.

Podéis revisar otros comandos como snapmirror abort para cancelar la sincronización, snapmirror break, snapmirror resync, etc.

Gestión de particiones con parted en Linux

gnu partedHace un tiempo aprendimos a gestionar discos y particiones con fdisk, ahora vamos ver como trabajar con el programa GNU parted, que permite particionar y redimensionar discos, así como crear, redimensionar y copiar sistemas de fichero extX, swap, FAT y FAT32 (luego veremos que es recomendable utilizar las herramientas propias de Linux en lugar que las que ofrece parted en algunos casos).

Vamos a partir de un disco (virtual) sin particionar. Lo primero que vemos al acceder a parted es un error, ya que parted necesita que el disco tenga una etiqueta (LABEL) para poder trabajar con él:

# parted /dev/sdb
GNU Parted 2.1
Usando /dev/sdb
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) print                                                            
Error: /dev/sdb: unrecognised disk label

Normalmente se utiliza la etiqueta ‘msdos’ ya que Microsoft y OS/2 es la que reconocen, así que la asignamos con el comando mklabel:

(parted) mklabel                                                          
¿Nuevo tipo de etiqueta de disco? msdos

En todo momento podéis ver los comandos disponibles escribiendo el signo de interrogación (?)

(parted) ?                                                                
  align-check TYPE N                        check partition N for TYPE(min|opt) alignment
  check NUMBER                             do a simple check on the file system
  cp [DESDE-DISPOSITIVO] DE-NUMERO A-NUMERO   copia el sistema de ficheros a otra partición
  help [COMMAND]                           print general help, or help on COMMAND
  mklabel,mktable LABEL-TYPE               create a new disklabel (partition table)
  mkfs NUMBER FS-TYPE                      make a FS-TYPE file system on partition NUMBER
  mkpart TIPO-PART [TIPO-SF] INICIO FIN     crea una partición
  mkpartfs TIPO-PART TIPO-SF INICIO FIN     crear una partición con un sistema de ficheros
...
...
...

print: listar discos duros, particiones y espacio libre

El comando print nos permite por un lado mostrar todos los dispositivos (discos duros) reconocidos por el sistema:

(parted) print devices                                                    
/dev/sdb (268MB)
/dev/sda (12,7GB)

También las particiones de cada uno y/o el espacio libre:

(parted) print free                                                       
Model: ATA VBOX HARDDISK (scsi)
Disk /dev/sdb: 268MB
Sector size (logical/physical): 512B/512B
Partition Table: msdos

Numero  Inicio  Fin    Tamaño  Typo  Sistema de ficheros  Banderas
        32,3kB  268MB  268MB         Free Space

mkpart: crear una partición sin filesystem

Parted nos da la opción de crear una partición y al mismo tiempo el sistema de ficheros (lo vemos más adelante), pero de momento únicamente vamos a crear una partición estándar sin asignar filesystem. Podemos hacer dos cosas, o seguir el asistente o escribir la línea de comandos completa directamente. Para comenzar lo más sencillo es el asistente:

Partición primaria de 100MB que será usada como filesystem ext4

(parted) mkpart
¿Tipo de partición?  primary/primaria/extended/extendida? primary         
¿Tipo de sistema de ficheros?  [ext2]? ext4                               
¿Inicio? 1                                                                
¿Fin? 100

Si ejecutamos un print list veremos la nueva partición lista para ser formateada con mkfs.ext4:

(parted) print                                                            
Model: ATA VBOX HARDDISK (scsi)
Disk /dev/sdb: 268MB
Sector size (logical/physical): 512B/512B
Partition Table: msdos

Numero  Inicio  Fin     Tamaño  Typo     Sistema de ficheros  Banderas
 1      1049kB  99,6MB  98,6MB  primary

mkpartfs: crear una partición con filesystem

Como comentaba antes, parted permite dar formato a la partición en el proceso de creación, aunque claramente vemos al ejecutarlo que recomiendan encarecidamente hacer uso de las herramientas adecuadas para ello (mkfs.extX, e2fsprogs). Así que simplemente vamos a ver como hacerlo por curiosidad (además no soporta ni ext3 ni ext4, sólo ext2…):

WARNING: you are attempting to use parted to operate on (mkpartfs) a file system.
parted’s file system manipulation code is not as robust as what you’ll find in
dedicated, file-system-specific packages like e2fsprogs. We recommend
you use parted only to manipulate partition tables, whenever possible.
Support for performing most operations on most types of file systems
will be removed in an upcoming release.

(parted) mkpartfs                                                         
WARNING: you are att.....
will be removed in an upcoming release.
¿Tipo de partición?  primary/primaria/extended/extendida? primary         
¿Tipo de sistema de ficheros?  [ext2]? ext2                               
¿Inicio? 100                                                              
¿Fin? 200

Y ya tenemos la partición con sistema de ficheros ext2:

(parted) print                                                            
Model: ATA VBOX HARDDISK (scsi)
Disk /dev/sdb: 268MB
Sector size (logical/physical): 512B/512B
Partition Table: msdos

Numero  Inicio  Fin     Tamaño  Typo     Sistema de ficheros  Banderas
 1      1049kB  99,6MB  98,6MB  primary
 2      99,6MB  200MB   101MB   primary  ext2
# mount /dev/sdb2 /test
# df -h | grep /test
/dev/sdb2              90M   13K   86M   1% /test
# umount /test

rm: eliminar una partición

Para eliminar una partición con parted es tan simple como ejecutar “rm” seguido del número de la partición:

(parted) print                                                            
Model: ATA VBOX HARDDISK (scsi)
Disk /dev/sdb: 268MB
Sector size (logical/physical): 512B/512B
Partition Table: msdos

Numero  Inicio  Fin     Tamaño  Typo     Sistema de ficheros  Banderas
 1      1049kB  99,6MB  98,6MB  primary
 2      99,6MB  200MB   101MB   primary  ext2
(parted) rm 2  /pre>

check: comprobación de un filesystem

Existen otras opciones, como por ejemplo hacer un check al sistema de ficheros, pero igual que con mkpartfs recomiendan utilizar herramientas propias del sistema como fsck. Además, no soportan sistemas de ficheros ext4 o ext3:

(parted) check 1                                                          
WARNING: you are attempting to use parted to operate on (check) a file system.
parted's file system manipulation code is not as robust as what you'll find in
dedicated, file-system-specific packages like e2fsprogs.  We recommend
you use parted only to manipulate partition tables, whenever possible.
Support for performing most operations on most types of file systems
will be removed in an upcoming release.
Sin Implementación: El soporte para abrir el sistema de ficheros ext4 aún no está implementado.


Si revisáis la página man o la propia salida de ‘?’ veréis otras opciones, como mkfs para formatear sistemas de ficheros (como comentaba antes, no recomendable) y otras más interesantes como rescue, que permite recuperar una partición perdida indicando su posición de inicio y fin:

(parted) rescue INICIO FIN

Os recomiendo como siempre revisar la página man o la salida de ‘?’ para descubrir todas sus posibilidades, como redimensionar una partición con resize, moverla con move, etc. Eso sí, recordad que es preferible usar los comandos/herramientas propios del sistema para mayor seguridad en estos casos.

Montar un filesystem por UUID o label

disco duroEl beneficio de montar los sistemas de ficheros con su UUID o label en lugar de con el nombre asignado a la partición (/dev/sda1, /dev/hda2…) es que se trata de un identificador único, como su propio nombre indica: Universally Unique Identifier (UUID). Esto evita problemas que se pueden producir cuando añadimos nuevos dispositivos al sistema, movemos particiones, etc ya que el nombre de la partición puede cambiar pero no el UUID o label (etiqueta asignada por nosotros).

¿Cómo averiguamos el UUID de una partición?

Hay varias formas: con el comando blkid, tune2fs… Vamos a localizar el UUID de la partición /dev/sda2:

# tune2fs -l /dev/sda2 | grep UUID
Filesystem UUID:          528c141b-66fd-43d5-808b-4a94a639f323
# blkid /dev/sda2
/dev/sda2: UUID="528c141b-66fd-43d5-808b-4a94a639f323" TYPE="ext4"

Con esta información ya podemos añadir la entrada correspondiente al fichero /etc/fstab. Si antes estaba así:

/dev/sda2     /datos               ext4    defaults        1 1

Ahora quedaría así:

UUID=528c141b-66fd-43d5-808b-4a94a639f323     /datos        ext4    defaults   1 1

¿Y cómo averiguamos o configuramos la etiqueta del filesystem?

Es sencillo, con el comando tune2fs seguido del parámetro -L podemos configurar la etiqueta que queramos:

# tune2fs -L "DATOS" /dev/sda2
tune2fs 1.41.12 (17-May-2010)

Para consultar la etiqueta/label de la partición:

# tune2fs -l /dev/sda2 | grep "Filesystem volume name"
Filesystem volume name:   DATOS

También podemos verla con el comando anterior blkid, ahora que la partición tiene label nos muestra tanto el UUID como la etiqueta:

# blkid /dev/sda2
/dev/sda2: UUID="528c141b-66fd-43d5-808b-4a94a639f323" TYPE="ext4" LABEL="DATOS"

Y para montarla en /etc/fstab tan sencillo como:

LABEL=DATOS     /datos        ext4    defaults   1 1

Autofs y automount para servir nfs

Algunos de los pros de automount/autofs frente a montar sistemas de ficheros de forma estática es su dinamismo y simplicidad. Si utilizamos automount para servir nfs podemos conseguir que el export NFS únicamente esté montado cuando realmente es necesario, reduciendo la posibilidad de corrupción del sistema de ficheros. Si es un filesystem con pocos accesos también es útil no tenerlo montado de forma permanente y establecer un timeout.

En la parte práctica, nfs con automount es muy útil para servir las /home de usuarios, pudiendo el usuario tener un mismo directorio home centralizado para varias máquinas, también para repositorios de software compartido, etc. Vamos a ver el ejemplo más sencillo de servir un directorio por nfs y automount en unas máquinas CentOS:

Requisitos

Necesitaremos estos dos paquetes:

# yum install nfs-utils autofs

Disponer de una NAS o servidor NFS con un export configurado (IP 192.168.1.144), por ejemplo:

# more /etc/exports
/repo *(rw)

Configuración automount en los clientes

El fichero de configuración principal es /etc/auto.master, en el cual se especifican los mapeos, puntos de montaje y parámetros de configuración. Muchas veces, por limpieza y tener mejor estructuración, los parámetros y puntos de montaje se especifican en ficheros aparte (/etc/auto.misc o el que queramos).

Nosotros queremos por un lado, mapear el directorio local /export con el sistema de ficheros NFS. De momento establecemos esta configuración en auto.master (Tenéis ejemplos en el fichero así como comentarios de ayuda):

/export        /etc/auto_repo

Y en el fichero /etc/auto_repo especificamos punto de montaje, flags del filesystem y el export NFS:

repo	-fstype=nfs,rw,nosuid	192.168.1.144:/repo

Iniciamos servicios autofs y nfs:

/etc/init.d/nfs start && /etc/init.d/autofs start

Vemos los puntos de montaje actuales:

# df -h
S.ficheros            Size  Used Avail Use% Montado en
/dev/sda2             7,7G  970M  6,4G  13% /
tmpfs                 376M     0  376M   0% /dev/shm
/dev/sda1             485M   28M  432M   7% /boot
/dev/sda5            1008M   34M  924M   4% /home

Entramos en /export/repo y volvemos a revisar los puntos de montaje, aparece automáticamente el export NFS:

Nota: con automount tienes que saber el path directo, no puedes usar [TAB]

# cd /export/repo
[root@server1 repo]# df -h
S.ficheros            Size  Used Avail Use% Montado en
/dev/sda2             7,7G  970M  6,4G  13% /
tmpfs                 376M     0  376M   0% /dev/shm
/dev/sda1             485M   28M  432M   7% /boot
192.168.1.144:/repo   7,7G  963M  6,4G  13% /export/repo

Una vez pasado el timeout especificado el punto de montaje quedaría desmontado automáticamente. Este es el ejemplo más básico de automount y autofs, podríamos llegar a montar vía export todas las home de usuario, Autofs + LDAP y otras configuraciones más complejas. De momento esta es la idea básica sobre la que podéis comenzar a trabajar. Os dejo unos enlaces recomendados para aprender más sobre autofs:

  1. Automount y autofs en es.tldp.org
  2. Automounter examples en www.linux-consulting.com

Encriptar un filesystem con LUKS y cryptsetup

luksLUKS (Linux Unified Key Setup) es un cifrado que trabaja a nivel de bloque de fichero sobre la partición o volumen lógico y que permite encriptar sistemas de ficheros, para los cuales es necesaria una passphrase o keyfile para su desencriptado. Encriptar un sistema de ficheros es especialmente útil cuando trabajamos con información sensible en dispositivos físicos portatiles, como por ejemplo pendrives, ordenadores portátiles, etc.

Vamos a encriptar un sistema de ficheros de un disco secundario sobre un sistema RHEL 6 (CentOS). Para encriptar particiones de sistema (filesystem / o /home por ejemplo) es preferible hacerlo en el momento de la instalación, ya que resulta más sencillo y evitamos la pérdida de datos posterior.

Preparación del sistema

Para la encriptación con LUKS necesitamos tener cargado el módulo de kernel dm_crypt así como el paquete cryptsetup-luks:

# lsmod | grep dm_cry
dm_crypt               10848  0 
dm_mod                 63859  5 dm_crypt,dm_mirror,dm_log

Si no está cargado en vuestro sistema hacedlo con modprobe:

# modprobe dm_crypt

Acordaos de configurarlo (por defecto es probable que con modprobe sea suficiente) para que sea persistente a reinicios.

Instalamos cryptsetup-luks en caso de que no esté instalado:

# yum install cryptsetup-luks
# rpm -qa | grep cryptse
cryptsetup-luks-libs-1.1.2-2.el6.i686
cryptsetup-luks-1.1.2-2.el6.i686

Preparación del sistema de ficheros/partición

Vamos a asumir que tenemos ya el sistema de ficheros creado. Podéis revisar los siguientes artículos si tenéis dudas, tanto de crear una partición estándar como un LVM:

Algo recomendable pero que suele llevar bastante tiempo es, lo primero de todo, llenar de datos aleatorios la partición a encriptar. Repito que puede llevar bastante tiempo dependiendo del tamaño de la partición. Si sólo estáis haciendo pruebas no es necesario que lo hagáis (sustituid /dev/volgroup1/logvol1 por vuestra partición o volumen):

# dd if=/dev/urandom of=/dev/volgroup1/logvol1

Encriptación del filesystem

Llegados a este punto ya tenemos el sistema de ficheros preparado para su encriptación. Haremos uso del comando cryptsetup. Lo primero que haremos es asignar la passphrase. Cuanto más compleja sea mejor, igual que cualquier password:

Nota: se eliminará cualquier dato del filesystem

# cryptsetup luksFormat /dev/volgroup1/logvol1

WARNING!
========
This will overwrite data on /dev/volgroup1/logvol1 irrevocably.

Are you sure? (Type uppercase yes): YES
Enter LUKS passphrase: *********
Verify passphrase: *********

Al tratarse de un filesystem encriptado debemos mapearlo ya que no se puede leer directamente. Esa unidad mapeada será la que montaremos y utilicemos como un filesystem estándar. Vamos a sacar el UUID del sistema de ficheros encriptado para utilizarlo si queremos en lugar de la etiqueta (LABEL):

# cryptsetup luksUUID /dev/volgroup1/logvol1
79da86ea-70f2-4a80-82cb-6c614a885a37

Mapeamos el sistema de ficheros contra encrypted-fs:

# cryptsetup luksOpen /dev/volgroup1/logvol1 encrypted-fs
Enter passphrase for /dev/volgroup1/logvol1:

Y ya tenemos el volumen listo para particionar en /dev/mapper/encrypted-fs. Le damos formato y lo montamos:

# mkfs.ext4 /dev/mapper/encrypted-fs

Finalmente, lo añadimos a fstab para el arranque al inicio del sistema. Podemos hacerlo con el UUID o con la etiqueta (LABEL) del fs:

# tune2fs -l /dev/mapper/encrypted-fs | grep UUID
Filesystem UUID:          9578a03e-949b-4fe8-a16c-57024b01fe89

Lo añadimos a /etc/fstab:

UUID=9578a03e-949b-4fe8-a16c-57024b01fe89 /encrypted-fs ext4    defaults 0 0

Y añadimos también la siguiente entrada a /etc/crypttab para que solicite la passphrase en el arranque del sistema:

encrypted-fs /dev/volgroup1/logvol1 none

Si reiniciáis, durante el arranque se os solicitará la passphrase del volumen:

logvol1 is password protected: *************

Gestionar el storage en Solaris con zfs y zpool

disco duroLa administración de discos y sistemas de ficheros zfs en Solaris (y en BSD) es algo distinta a lo que estamos acostumbrados para otros entornos Unix y GNU/Linux (ext3, ext4…). Zfs es un sistema de ficheros de 128-bit con una gran escalabilidad, estabilidad, transaccional y con una especial seguridad en la integridad de los datos. Pero no vamos a entrar en estos detalles sino en cómo gestionar este sistema.

Los dos comandos que debemos conocer para trabajar con sistemas de ficheros zfs son zpool y zfs. zpool es la primera capa de abstracción, crea pools de discos que pueden gestionar a su vez X sistemas de ficheros. A posteriori, se pueden añadir más discos al pool y automáticamente los sistemas de ficheros reciben este espacio sin gestión extra, algo excepcional para la escalabilidad.

Vamos a añadir un pool de prueba con un disco extra que tenemos en nuestro sistema. Podemos ver los discos físicos con el comando iostat -En:

# iostat -En
c7d0             Soft Errors: 0 Hard Errors: 0 Transport Errors: 0
Model: VBOX HARDDISK   Revision:  Serial No: VB5d392fb1-ed1f Size: 7,13GB
Media Error: 0 Device Not Ready: 0 No Device: 0 Recoverable: 0
Illegal Request: 0
c7d1             Soft Errors: 0 Hard Errors: 0 Transport Errors: 0
Model: VBOX HARDDISK   Revision:  Serial No: VBf793d417-2c8e Size: 1,07GB
Media Error: 0 Device Not Ready: 0 No Device: 0 Recoverable: 0
Illegal Request: 0
c8d1             Soft Errors: 0 Hard Errors: 0 Transport Errors: 0
Model: VBOX HARDDISK   Revision:  Serial No: VBf3c2659f-ea9c Size: 1,07GB
Media Error: 0 Device Not Ready: 0 No Device: 0 Recoverable: 0
Illegal Request: 0
c8t0d0           Soft Errors: 0 Hard Errors: 6 Transport Errors: 0
Vendor: VBOX     Product: CD-ROM           Revision: 1.0  Serial No:
Size: 0,00GB
Media Error: 0 Device Not Ready: 6 No Device: 0 Recoverable: 0
Illegal Request: 0 Predictive Failure Analysis: 0

El disco c7d0 es el que engloba el sistema y su propio pool (rpool), así que creamos de momento un nuevo pool llamado rpool2 con el disco c7d1:

# zpool rpool2 c7d1

Una vez realizado, automáticamente el pool se crea y es visible con un df -h, englobando todo el espacio del disco, se monta sólo:

# df -h /rpool2
Filesystem            Size  Used Avail Use% Mounted on
rpool2                976M   31K  976M   1% /rpool2

Ahora podemos comenzar a crear sistemas de ficheros dentro del pool con el comando zfs, creamos el sistema de ficheros /rpool2/test, que se monta de forma automática:

# zfs create rpool2/test
# df -h | grep rpool2
rpool2                976M   32K  976M   1% /rpool2
rpool2/test           976M   31K  976M   1% /rpool2/test

Lo interesante de esto es que una vez establecidos los pool, en caso de necesitar agregar más espacio a alguno de ellos, es tan sencillo como agregar nuevos discos al pool, automáticamente el espacio se asignará a los sistemas de ficheros que contiene. Yo tengo otro disco c8d1 así que lo voy a agregar para aumentar al doble el espacio del pool y sus sistemas de ficheros. Usaremos el comando zpool add seguido del pool y los discos a añadir:

# zpool add rpool2 c8d1

Y ya está, nuestro pool ha aumentado al doble su capacidad sin mayor gestión:

# df -h | grep rpool2
rpool2                2,0G   32K  2,0G   1% /rpool2
rpool2/test           2,0G   31K  2,0G   1% /rpool2/test

Si queremos tener una visión global de los pool en el sistema utilizamos el comando zpool list:

# zpool list
NAME     SIZE  ALLOC   FREE    CAP  DEDUP  HEALTH  ALTROOT
rpool   6,56G  2,93G  3,63G    44%  1.00x  ONLINE  -
rpool2  1,97G   132K  1,97G     0%  1.00x  ONLINE  -

Por supuesto, no tenemos porque dejar que todos los sistemas de ficheros dispongan de todo el espacio del pool, podemos limitarlo estableciendo quotas:

# zfs set quota=200M rpool2/test
# df -h | grep test
rpool2/test           200M   31K  200M   1% /rpool2/test

Podría decirse que esto es lo más básico, la conclusión que podemos sacar es que, es una forma distinta de trabajar los discos y sistemas de ficheros, pero una vez acostumbrados es bastante más sencilla y práctica que los sistemas de ficheros tradicionales. Podemos seguir investigando las opciones de zpool y zfs con sus páginas man. Encontraremos otras utilidades de gran importancia, por ejemplo la posibilidad de visualizar el estado de IO en los pools:

# zpool  iostat rpool2
               capacity     operations    bandwidth
pool        alloc   free   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
rpool2       132K  1,97G      0      2  1,69K  14,6K

Os invito a investigar un poco, es un sistema lleno de posibilidades y realmente interesante, deduplicación, compresión, snapshots

Gestión de snapshots en ZFS

ZFS (sistema de archivos desarrollado por Sun Microsystems para Solaris) permite realizar snapshots del sistema de ficheros de forma instantanea a través del comando zfs snapshot. Básicamente, un snapshot es una copia exacta del sistema de ficheros que posteriormente podemos utilizar para clonar, restaurar, guardar a modo de copia antes de la realización de cambios críticos en el sistema, etc. Lo que no podemos hacer es manipularlos, los snapshots son copias de sólo lectura.

Los snapshot se almacenan en el propio disco, por lo que su utilización supone la utilización de espacio extra y no sirven como backup en caso de desastre. Inicialmente no ocupan espacio extra, pero sí lo hacen conforme la información del sistema de ficheros cambia respecto al snapshot.

Crear, destruir y renombrar un snapshot

La sintaxis básica para la creación de un snapshot es la siguiente:

# zfs snapshot sistema_de_ficheros@nombre_snapshot

Por ejemplo, para crear un snapshot de “rpool/ROOT/solaris” con nombre la fecha de hoy:

# zfs snapshot rpool/ROOT/solaris@`date +%d%m%Y`

Para eliminar el snapshot usamos el comando zfs destroy:

# zfs destroy rpool/ROOT/solaris@04102011

Y para renombrarlo:

# zfs rename rpool/ROOT/solaris@04102011 rpool/ROOT/solaris@nuevo-snap

Listar snapshots disponibles

# zfs list -t snapshot
NAME                          USED  AVAIL  REFER  MOUNTPOINT
rpool/ROOT/solaris@install   22,5M      -  2,04G  -
rpool/ROOT/solaris@04102011    37K      -  2,44G  -

Con el comando zfs list -t snapshot podemos ver un listado de todos los snapshot disponibles, los snapshots se almacenan en el directorio oculto .zfs de la ruta base donde está montado el sistema de ficheros, en el caso de los anteriores /.zfs/snapshot. De esta forma podríamos restaurar ficheros concretos del snapshot en lugar de todo:

# ls -l /.zfs/snapshot
total 5
drwxr-xr-x 24 root root 25 2011-10-03 21:17 04102011
drwxr-xr-x 24 root root 25 2011-10-03 21:17 10042011
drwxr-xr-x 24 root root 26 2011-09-22 18:42 install

También conviene revisar el espacio en disco utilizado, el comando zfs list -o space nos mostrará con detalle el espacio utilizado a nivel general, por los snapshot, subsistemas de ficheros (child), etc:

# zfs list -o space
NAME                    AVAIL   USED  USEDSNAP  USEDDS  USEDREFRESERV  USEDCHILD
rpool                   3,19G  3,27G         0   92,5K              0      3,27G
rpool/ROOT              3,19G  2,46G         0     31K              0      2,46G
rpool/ROOT/solaris      3,19G  2,46G     22,5M   2,44G              0          0
rpool/dump              3,19G   256M         0    256M              0          0
rpool/export            3,19G  26,2M         0     32K              0      26,2M
rpool/export/home       3,19G  26,2M         0     32K              0      26,2M
rpool/export/home/alex  3,19G  26,2M       20K   26,2M              0          0
rpool/swap              3,54G   544M         0    181M           364M          0

Restaurar un snapshot

Hacer un rollback o restaurar un snapshot es tan sencillo como utilizar el comando zfs rollback seguido del snapshot a restaurar. Lo que hay que tener claro son las consecuencias de restaurar un snapshot antiguo, ya que restauremos el sistema de ficheros tal y como se encontraba en el momento del snapshot.

Algo a tener en cuenta, es que únicamente podemos restaurar el snapshot más reciente. Si tuvieramos varios y quisieramos hacer rollback de uno antiguo, antes habría que eliminar los más recientes. Recibiríamos este error:

# zfs rollback rpool/ROOT/solaris@10042011
cannot rollback to 'rpool/ROOT/solaris@10042011': more recent snapshots exist
use '-r' to force deletion of the following snapshots:
rpool/ROOT/solaris@04102011

Así que eliminaríamos el reciente y ya podríamos hacerlo, también podríamos forzar con el parámetro -r a que se eliminan automáticamente:

# zfs destroy rpool/ROOT/solaris@04102011
# zfs rollback rpool/ROOT/solaris@10042011
# zfs rollback -r rpool/ROOT/solaris@10042011