Porque NO usar particiones para Luns o discos virtuales exclusivos para datos en RHEL/CentOS/SL

Porque NO usar particiones para Luns o discos virtuales exclusivos para datos en RHEL/CentOS/SL

El problema al momento de querer extender un disco virtual o lun de datos es que por mas que el sistema operativo reconozca el tamaño nuevo del disco, al momento de querer utilizar ese espacio nuevo es necesario extender la particion, o de utlima crear una particion nueva. Esto requiere reinicios en caso de que el disco se este utilizando, el reinicio es para que el S.O. vuelva a leer la tabla de particiones.

La forma de evitar tener que reiniciar cada vez que querramos extender nuestra LUN o disco virtual es implementando LVM sobre el disco directo sin particion

Primero crearemos el Volume Group de forma directa sobre la LUN o disco virtual

En este ejemplo lo haremos con un disco virtual exclusivo para datos de 10GB que es el /dev/sdb

Lo primero que tenemos que hacer es verificar que el S.O. vea el disco

# fdisk -l /dev/sdb
 
Disk /dev/sdb: 10.7 GB, 10737418240 bytes, 20971520 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

Verificamos que el disco este vacio

# dd if=/dev/sdb bs=512 count=2 |strings
2+0 registros leídos
2+0 registros escritos
1024 bytes (1,0 kB) copiados, 0,00250696 s, 408 kB/s

No nos muestra nada por lo tanto esta vacio

Formateamos el disco completo como Physical Volume

# pvcreate /dev/sdb
  Physical volume "/dev/sdb" successfully created

Creamos un Volume Group

# vgcreate testvg /dev/sdb
  Volume group "testvg" successfully created

Luego creamos un Logical Volume de pruebas con 8G

# lvcreate -n testlv -L8G testvg
  Logical volume "testlv" created.

Creamos un FS XFS sobre el volumen y lo montamos en el /mnt

# mkfs.xfs /dev/testvg/testlv
# mount  /dev/testvg/testlv /mnt
# df -h /mnt/
S.ficheros                Tamaño Usados  Disp Uso% Montado en
/dev/mapper/testvg-testlv   8,0G    33M  8,0G   1% /mnt

Ahora ampliamos el disco desde la consola de administracion de VMWARE o el virtualizador que usemos (esto no lo voy a mostrar aca)

Es necesario re-escanear el disco desde el S.O. para que este vea el nuevo tamaño

Esto lo hacemos con el siguiente comando:

echo 1 > /sys/class/block/#dispositivo/device/rescan

Donde #dispositivo es el nombre de nuestro disco en cuestion, en este caso lo haremos sobre la sda.

echo 1 > /sys/class/block/sdb/device/rescan

Hecho esto el S.O. ya deberia reconocer el nuevo tamaño, por ende podemos ampliar nuestra particion

#  fdisk -l /dev/sdb
 
Disk /dev/sdb: 21.5 GB, 21474836480 bytes, 41943040 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

Luego debemos extender el Physical Volume

# pvresize /dev/sdb
  Physical volume "/dev/sdb" changed
  1 physical volume(s) resized / 0 physical volume(s) not resized
# vgs testvg
  VG     #PV #LV #SN Attr   VSize  VFree
  testvg   1   1   0 wz--n- 20,00g 12,00g

Con el comando vgs verificamos que el Volume Group reconocio el nuevo espacio. Luego podemos extender nuestro Logical Volume para que llegue a los 18G

# lvresize -L18G /dev/testvg/testlv
  Size of logical volume testvg/testlv changed from 8,00 GiB (2048 extents) to 18,00 GiB (4608 extents).
  Logical volume testlv successfully resized.

Con esto ya podemos extender nuestro FileSystem

# xfs_growfs /dev/testvg/testlv
meta-data=/dev/mapper/testvg-testlv isize=256    agcount=4, agsize=524288 blks
         =                       sectsz=512   attr=2, projid32bit=1
         =                       crc=0        finobt=0
data     =                       bsize=4096   blocks=2097152, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0 ftype=0
log      =internal               bsize=4096   blocks=2560, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0
data blocks changed from 2097152 to 4718592
 
 
# df -h /dev/testvg/testlv
S.ficheros                Tamaño Usados  Disp Uso% Montado en
/dev/mapper/testvg-testlv    18G    33M   18G   1% /mnt

Con esto evitamos la necesidad de reiniciar nuestros equipos para extender nuestros discos virtuales o LUNs

Uno de los puntos mas importantes es detectar si los discos contienen datos antes de formatearlos.

Detectar si un disco esta siendo utilizado

Para detectar si un disco esta siendo utilizado podemos utilizar el comando dd de la siguiente forma:

dd if=/dev/sdb bs=512 count=2 |strings
Si el disco esta vacio deberia mostrar algo parecido a lo siguiente

# dd if=/dev/sdb bs=512 count=2 |strings
2+0 registros leídos
2+0 registros escritos
1024 bytes (1,0 kB) copiados, 0,00250696 s, 408 kB/s

En caso que tenga LVM deberia de mostrar algo parecido a lo siguiente:

# dd if=/dev/sdb bs=512 count=2 | strings
2+0 records in
2+0 records out
LABELONE
LVM2 0016hxjXHBW8Bm1xLnQZoEBDoKzWi0x8IRG
1024 bytes (1.0 kB) copied, 7.9217e-05 s, 12.9 MB/s

Redimensionar dispositivo multipath

Como hacer resize de LUNs y gestionadas por multipath

Detectar dispositivos fisicos

Primero debemos detectar cuales son los dispositivos fisicos o "sd" que hacen referencia a nuestro dispositivo multipath

Dichos dispositivos los podemos detectar ejecutando

multipath -ll nombredeldispositivo

Ej:

[root@c7kl ~]# multipath -ll hus1_bd1
hus1_bd1 (360060e80101b6840058bb6540000007f) dm-4 HITACHI ,DF600F
size=150G features='1 queue_if_no_path' hwhandler='0' wp=rw
|-+- policy='service-time 0' prio=1 status=active
| `- 0:0:0:0 sda 8:0   active ready running
`-+- policy='service-time 0' prio=0 status=enabled
  `- 2:0:0:0 sdk 8:160 active ready running

Si nos fijamos en los detalles de cada camino:

`- 0:0:0:0 sda 8:0 active ready running

`- 2:0:0:0 sdk 8:160 active ready running

Vemos que los dispotivos fisicos son "sda" y "sdk"

Re-escaner dispositivos fisicos

Luego de identificar procedemos a re-escaner los dispositivos fisicos, la manera de hacerlo es la siguiente:

echo 1 > /sys/class/block/sdX/device/rescan

Reemplazando sdX por nuestros dispositivos fisicos.

Segun el ejemplo anterior

[root@c7kl ~]# echo 1 > /sys/class/block/sda/device/rescan
[root@c7kl ~]# echo 1 > /sys/class/block/sdk/device/rescan

Redimensionar el dispositivo logico

Finalmente para redimensionar el dispositivo logico debemos utilizar el comando multipathd con la opcion -k, la sintaxis es la siguiente:

multipathd -k'resize map nombredeldispositivo'

Siguiendo nuestro ejemplo:

[root@c7kl ~]# multipathd -k'resize map hus1_bd1'

Luego verificamos el tamaño de nuestro dispositivo con el comando multipathd -ll nombredeldispositivo

[root@c7kl ~]# multipath -ll hus1_bd1
hus1_bd1 (360060e80101b6840058bb6540000007f) dm-4 HITACHI ,DF600F          
size=300G features='1 queue_if_no_path' hwhandler='0' wp=rw
|-+- policy='service-time 0' prio=1 status=active
| `- 0:0:0:0 sda 8:0   active ready running
`-+- policy='service-time 0' prio=0 status=enabled
  `- 2:0:0:0 sdk 8:160 active ready running

Donde finalmente podemos ver el nuevo tamaño

Migrar S.O. RHEL/CentOS/SL 7 que bootea por SAN

Migrar S.O. RHEL/CentOS/SL 7 que bootea por SAN a otra LUN

Entorno

Sistema Operativo: CentOS 7.1
Lun Actual: /dev/mapper/emc_so
Lun Nueva: /dev/mapper/vsp_so
Particiones:

/boot -> /dev/mapper/emc_so1
LVM -> /dev/mapper/emc_so2

  • Volume Group -> rootvg
    • / -> rootlv
    • /tmp -> tmplv
    • /home -> homelv
    • /var -> varlv

Para lograr que la migracion se culmine de manera correcta se deben seguir los siguientes pasos:

1: Se debe presentar la lun nueva al equipo, y lograr que el equipo la reconozca:

Para que el S.O. reconozca la nueva LUN posiblemente sea necesario re-escanear o reiniciar las HBAs para eso podemos usar los siguientes comandos:

Escanear HBA: echo - - - > /sys/class/scsi_host/host#/scan

Reiniciar HBA: echo 1 > /sys/class/fc_host/host#/issue_lip

Donde # se debe reemplazar por el numero de HBA.

Se recomienda realizar un escaneo de todas las HBAs, en caso de que aun no se reconozco la lun se puede proceder a reiniciar las HBAs y luego volver a escanear las mismas.

En esta estapa se recomienda configurar el "nombre amigable" de la nueva lun, para esto debemos identificar el wwid de la lun nueva, el wwid es el valor que se muestra entre parentesis al ejecutar multipath -ll.

Por Ejemplo, si queremos identificar el wwid de una LUN presentada desde un Storage Hitachi:

[root@c7ke ~]# multipath -ll | grep HITACHI

mpathf (360060e80129f9b0050409f9b000002a1) dm-15 HITACHI ,OPEN-V

Una vez que tenemos el wwid de la lun nueva podemos asignarle un nombre amigable agregando la siguiente entrada en el archivo /etc/multipath.conf:

multipaths {
    multipath {
        wwid    360060e80129f9b0050409f9b000002a1
        alias   vsp_so
    }
}

Reemplanzando el wwid por el de la LUN nueva y el alias porque el nombre que elijamos.

Luego se debe "recargar" el servicio multipath para que tome los cambios:

service multipathd reload

2: Una vez que el equipo reconozca la Lun nueva es necesario particionar la misma.

Para clonar la tabla de particiones de la lun actual a la lun nueva podemos utilizar el comando sfdisk:

sfdisk -d /dev/mapper/emc_so | sfdisk /dev/mapper/vsp_so

Luego es necesario que el equipo reconozca las particiones creadas con el comando anterior:

partprobe /dev/mapper/vsp_so

3: Clonamos el /boot.

Como el /boot solo es accedido al momento del booteo del sistema lo podemos desmontar y clonar sin afectar el funcionamiento del S.O.

Para la clonacion de dicho FS podemos usar el comando dd:

umount /boot

dd if=/dev/mapper/emc_so1 of=/dev/mapper/vsp_so1 bs=5M

4: Movemos los volumenes LVM.

Si tenemos implementado LVM la migracion se simplifica bastante ya que con el comando pvmove se pueden mover datos en caliente.

Primero debemos crear los "Physical volumens"

pvcreate /dev/mapper/vsp_so2

Luego debemos extender nuestro "volume group" de manera a que la particion de la lun nueva sea parte del mismo.

vgextend rootvg /dev/mapper/vsp_so2

Procedemos a migrar los volumenes

pvmove /dev/mapper/emc_so2 /dev/mapper/vsp_so2

Una vez que termine la migracion de los volumenes podemos quitar del "volume group" la lun vieja.

vgreduce rootvg /dev/mapper/emc_so2

Finalmente debemos eliminar los PVs en la lun vieja para que al retirar no se presenten errores

5: Retirar la lun vieja.

Al culminar el paso 4 todo el Sistema Operativo esta sobre la Lun nueva, por lo tanto podemos despresentar la lun vieja de manera segura.

6: Montar el /boot

Una vez que retiramos la lun vieja podemos volver a montar el /boot. Para evitar errores al montar ese necesario hacer una recarga de los servicios manejados por el systemd, esto debido a que existe un unit-file que se encarga del /boot.

systemctl daemon-reload

En caso de que en el archivo /etc/fstab tengamos el /boot configurado a traves de UID, podemos montar el /boot con el siguiente comando:

mount /boot

En caso contrario debemos corregir el path en el fstab, cambiando /dev/mapper/emc_so1 por /dev/mapper/vsp_so1, luego ejecutamos:

mount /boot

7: Verificar configuracion del MultiPath:

Para que la migracion culmine de manera exitosa es muy importante tener bien configurado el multipath.

Una vez identificado el wwid de la lun nueva es sumamente importante verificar que la misma se encuentra dentro de 2 archivos:

/etc/multipath/wwids

Dentro del /etc/multipath/wwids deberiamos encontrar una linea parecida a la siguiente:
/360060e80129f9b0050409f9b000002a1/

[root@c7ke ~]# cat /etc/multipath/wwids | grep 360060e80129f9b0050409f9b000002a1
/360060e80129f9b0050409f9b000002a1/

Donde el valor dentro de las barras (/) debe se el wwid de la lun nueva

/etc/multipath/bindigs

Dentro del /etc/multipath/bindings deberiamos encontrar una linea parecida a la siguiente:
mpathf 360060e80129f9b0050409f9b000002a1

Ej:
Donde mpathf puede ser mpath[a-z] y el segundo valor debe ser el wwid de la lun nueva

[root@c7ke ~]# cat /etc/multipath/bindings | grep 360060e80129f9b0050409f9b000002a1
mpathf 360060e80129f9b0050409f9b000002a1

8: Eliminar cache de LVM

Para evitar problemas con el proximo inicio se recomienda eliminar la cache LVM:

rm /etc/lvm/cache/.cache

9: Configurar el grub2 con la lun nueva

Para dicha tarea es necesario editar el archivo /boot/grub2/device.map. El mismo debe contener lo siguiente:

(hd0) < ruta_de_la_lun_nueva >

Por ejemplo en nuestro caso nuestra lun tiene como nombre vsp_so. Por lo tanto el archivo debe contener lo siguiente:

(hd0) /dev/mapper/vsp_so

10: Instalar el grub2 en la nueva lun

Se debe instalar el grub2 directamente sobre la LUN

[root@c7ke ~]# grub2-install /dev/mapper/vsp_so

11: Volver a crear el Initial Ram Disk (initrd)

Luego de realizar y verificar todos los pasos anterios debemos volver a crear el initrd:

[root@c7ke ~]# cd /boot/
[root@c7ke boot]# dracut -f -v -a multipath

Reiniciar el Servidor

Finalmente podemos reiniciar el servidor, al reiniciar debemos cambiar la politica de booteo del mismo para apuntar a la nueva LUN