LVM (parte 2): crear y expandir volúmenes
Luego de haber tenido un post introductorio a LVM, explicaré en esta oportunidad cómo:
- Crear volúmenes físicos, grupos de volúmenes y volúmenes lógicos.
- Redimensionar los volúmenes.
- Eliminar volúmenes.
Preparándose para utilizar LVM
Para este tutorial utilizaré Debian. El mismo se puede aplicar a cualquier Linux, aunque daré ciertas cosas por supuestas además de mostrar algunos comandos específicos de los sistemas Debian like.
Antes que nada, será necesario contar con el soporte para LVM. Para ello:
testing:~# aptitude install lvm2
Creación de un volumen lógico
Para crear un volumen lógico es necesario primero crear los volúmenes físicos que se necesitarán y luego el grupo de volúmenes. Finalmente se podrá crear el volumen lógico que se busca y asignar un sistema de archivos al mismo. Para este paso vamos a suponer que tenemos un disco rígido nuevo, sin particionar. El disco en cuestión se identifica en el sistema como /dev/hdb.
Crear el volumen físico.
testing:~# pvcreate /dev/hdb Physical volume "/dev/hdb" successfully created
Crear el grupo de volúmenes.
testing:~# vgcreate testing /dev/hdb Volume group "testing" successfully created
Crear un volumen lógico.
testing:~# lvcreate testing -L 1.99G -n storage Rounding up size to full physical extent 1.99 GB Logical volume "storage" created testing:~# ls -l /dev/testing/storage lrwxrwxrwx 1 root root 27 2010-06-10 16:01 /dev/testing/storage -> /dev/mapper/testing-storage
Crear el sistema de archivos en el volumen lógico.
testing:~# mkfs.ext3 /dev/mapper/testing-storage
mke2fs 1.41.3 (12-Oct-2008)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
130560 inodes, 522240 blocks
26112 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=536870912
16 block groups
32768 blocks per group, 32768 fragments per group
8160 inodes per group
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912
Writing inode tables: done
Creating journal (8192 blocks): done
Writing superblocks and filesystem accounting information: done
This filesystem will be automatically checked every 23 mounts or
180 days, whichever comes first. Use tune2fs -c or -i to override.
Agregar el nuevo volumen al FSTAB.
testing:~# vi /etc/fstab /dev/mapper/testing-storage /storage ext3 defaults 0 2
Montar el nuevo sistema de archivos y probarlo.
testing:~# mkdir /storage
testing:~# mount /storage/
testing:~# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/testing-storage
2.0G 36M 1.9G 2% /storage
testing:~# echo "prueba" > /storage/archivo.txt
testing:~# cat /storage/archivo.txt
prueba
Redimensionar un volumen lógico
Hasta aquí se ha visto cómo crear volúmenes físicos, grupos de volúmenes y volúmenes lógicos. A su vez, se mostró cómo utilizar el volumen creado. En este punto se verá el tema de redimensionar el volumen lógico recién creado, primero agrandando su tamaño y luego achicándolo (tema de un próximo post). Es de destacar que el primero de los redimensionamientos será llevado a cabo sin desmontar el volumen lógico.
Aumentar el tamaño
En este punto se considerará que se tiene un disco rígido adicional identificado como /dev/hdc y que el mismo tiene dos particiones, /dev/hdc1 y /dev/hdc2. Se utilizará la primera de ellas para extender el volumen creado en los pasos anteriores.
Crear volumen físico.
testing:~# pvcreate /dev/hdc1 Physical volume "/dev/hdc1" successfully created
Extender el grupo de volúmenes.
En este paso se le indica al grupo de volúmenes testing que se le agregará un nuevo volumen físico.
testing:~# vgextend testing /dev/hdc1 Volume group "testing" successfully extended
Extender el volumen lógico.
El siguiente comando toma el volumen storage ya existente y le agrega 0.95G de tamaño, tomados a partir de la integración del nuevo volumen físico.
testing:~# lvextend -L +0.95G /dev/testing/storage Rounding up size to full physical extent 976.00 MB Extending logical volume storage to 2.95 GB Logical volume storage successfully resized
Redimensionar el sistema de archivos.
Hasta aquí está todo bien, sin embargo aún nuestro volumen no ha crecido en tamaño, según muestra la salida del comando df.
testing:~# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/testing-storage
2.0G 36M 1.9G 2% /storage
Lo que ha ocurrido es que, si bien el volumen ya cuenta con una mayor capacidad de almacenamiento, el sistema de archivos que se creó está limitando el tamaño del mismo. Por ello, es necesario extender el sistema de archivos existente. Este paso se realizará on-line, es decir, sin desmontar el volumen.
testing:~# resize2fs /dev/testing/storage
resize2fs 1.41.3 (12-Oct-2008)
Filesystem at /dev/testing/storage is mounted on /storage; on-line resizing required
old desc_blocks = 1, new_desc_blocks = 1
Performing an on-line resize of /dev/testing/storage to 772096 (4k) blocks.
The filesystem on /dev/testing/storage is now 772096 blocks long.
testing:~# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/testing-storage
2.9G 36M 2.8G 2% /storage
testing:~# cat /storage/archivo.txt
prueba
Como puede verse, el sistema de archivos ha sido extendido sin desmontar el volumen y los datos que se tenían fueron conservados.
Herramientas informativas
Es posible ver el estado y detalles de los diferentes volúmenes físicos, grupos de volúmenes y volúmenes lógicos mediante tres sencillos comandos que se muestran a continuación: pvdisplay, vgdisplay y lvdisplay.
testing:/home/leandro# pvdisplay --- Physical volume --- PV Name /dev/hdb VG Name testing PV Size 2.00 GB / not usable 4.00 MB Allocatable yes (but full) PE Size (KByte) 4096 Total PE 511 Free PE 0 Allocated PE 511 PV UUID pE7qSU-COhd-j6a4-YnWg-1mR7-xZ48-XDstZk --- Physical volume --- PV Name /dev/hdc1 VG Name testing PV Size 976.96 MB / not usable 984.50 KB Allocatable yes PE Size (KByte) 4096 Total PE 244 Free PE 1 Allocated PE 243 PV UUID rmvKFh-0hGJ-mBby-zPjT-eyvf-2CrP-TjTKG3 testing:/home/leandro# vgdisplay --- Volume group --- VG Name testing System ID Format lvm2 Metadata Areas 2 Metadata Sequence No 4 VG Access read/write VG Status resizable MAX LV 0 Cur LV 1 Open LV 1 Max PV 0 Cur PV 2 Act PV 2 VG Size 2.95 GB PE Size 4.00 MB Total PE 755 Alloc PE / Size 754 / 2.95 GB Free PE / Size 1 / 4.00 MB VG UUID epQoNY-6JWP-1vUX-IZm0-LRwo-4fR4-AEEo1p testing:/home/leandro# lvdisplay --- Logical volume --- LV Name /dev/testing/storage VG Name testing LV UUID ywXZGl-kafG-CoHV-3jGt-wt1S-rnlY-IBIgF8 LV Write Access read/write LV Status available # open 1 LV Size 2.95 GB Current LE 754 Segments 2 Allocation inherit Read ahead sectors auto - currently set to 256 Block device 254:2
Para la próxima
En otro nuevo post se mostrará cómo achicar un volumen lógico y cómo eliminar volúmenes lógicos, grupos de volúmenes y volúmenes físicos.
Proxmox: instalación, clustering y migración en vivo
En este post explicaré cómo instalar Proxmox con un particionamiento personalizado y cómo luego formar un cluster con otro equipo con Proxmox. Finalmente, daré una pauta de cómo lograr hacer la migración en vivo de máquinas virtuales.
En mi caso, cuento con dos servidores que soportan virtualización por hardware y he decidido utilizar Proxmox como plataforma de virtualización por varios motivos:
- Es software libre.
- Es gratis.
- Permite virtualizar con KVM y OpenVZ.
- Tiene una interfaz web muy sencilla de utilizar
- Basado en Debian: se lo puede administrar por SSH e instalar cualquier paquete compilado para Debian.
- Soporta varias funcionalidades avanzadas sin adquirir ninguna licencia adicional:
- Migración en vivo.
- Clustering de servidores.
- Backups automáticos de las VMs.
- Posibilidad de conectar a un NAS/SAN con NFS, iSCSI.
Instalación
La instalación de Proxmox es sumamente sencilla dado que se realiza en pocos pasos mediante una interfaz gráfica muy intuitiva. No obstante, cabe destacar que por defecto no se pregunta nada del esquema de particionamiento que utilizará. Desde mi punto de vista, la forma en que se particiona por defecto resulta muy ineficiente, dado que se asigna mucho espacio al directorio raíz y a la swap, espacio que normalmente no se utiliza.
No obstante, como el particionamiento se lleva a cabo utilizando LVM, es posible luego redimensionar esas particiones; sin embargo, es más sencillo escoger el tamaño al momento de la instalación para luego no tener que hacer ningún cambio. Para ello, cuando Proxmox bootea desde el CD la primera vez se queda esperando con un prompt que nos permite pasarle algún parámetro. En este caso, le indicaremos que deseamos un disco raíz de 20GB y una swap de 4GB, de la siguiente manera:
boot: linux maxroot=20 swapsize=4
Una vez finalizado lo anterior se prosigue la instalación guiada normalmente.
Armar el cluster
Contar con un cluster de servidores Proxmox es sumamente útil dado que posibilita migrar máquinas virtuales entre cualquier servidor del cluster y permite administrar todos los servidores Proxmox desde una única interfaz, ubicada en el master.
Por fortuna, crear el cluster con Proxmox es totalmente trivial y se realiza con los siguientes pasos (tener en cuenta que todos los equipos que formen parte del cluster deben tener nombres diferentes):
En el nodo que será el master:
dell:~# pveca -c cluster master successfully created dell:~# pveca -l CID----IPADDRESS----ROLE-STATE--------UPTIME---LOAD----MEM---DISK 1 : 10.31.1.67 M A 1 day 05:11 0.08 30% 3%
Luego, el segundo nodo, que será el esclavo:
virtua:~# pveca -l local node '10.31.1.60' not part of cluster virtua:~# pveca -a -h 10.31.1.67 cluster node successfully created virtua:~# pveca -l CID----IPADDRESS----ROLE-STATE--------UPTIME---LOAD----MEM---DISK 1 : 10.31.1.67 M A 1 day 05:13 0.01 30% 3% 2 : 10.31.1.60 N A 01:57 0.00 11% 2%
Con lo anterior ya se conformó el cluster entre ambos equipos. Si se accede por web a https://10.31.1.67 se podrá ver el estado de ambos servidores así como las máquinas virtuales con las que cuentan los mismos (en este caso ninguna dado que aún no hemos creado). Lógicamente, desde dicha interfaz podrán apagarse, prenderse, reiniciarse y modificarse las distintas máquins virtuales.
Migración en vivo
Para la migración en vivo se necesita utilizar un servidor NAS/SAN en el que se alojen los discos de las máquinas virtuales. El motivo de esto es que para lograr la migración en vivo, lo único que se hace es mover la información que la máquina a ser migrada tiene en memoria, de un equipo al otro. Como el disco es compartido por estar en un servidor de almacenamiento no cambia nada allí; además la migración gracias a esto se hace muy rápido.
Como en este caso sólo se tienen dos servidores, se utilizará el nodo master como servidor de almacenamiento. Para ello, se creará un directorio que luego será exportado por NFS y agregado a la sección “Storage”. Lo primero se realiza de la siguiente forma:
dell:~# aptitude install nfs-kernel-server dell:~# mkdir /var/lib/vz/storage dell:~# vi /etc/exports /var/lib/vz/storage 10.31.1.60(rw,no_root_squash) 10.31.1.67(rw,no_root_squash) dell:~# /etc/init.d/nfs-kernel-server restart
Listo, sólo resta agregar el nuevo dispositivo de almacenamiento por medio de la interfaz web. Luego, cuando se cree una máquina virtual y un disco para la misma se debe guardar este último en el almacenamiento de red. Teniendo esto hecho, el paso de migrar las máquinas virtuales en vivo es tan sencillo que ni vale la pena que lo explique aquí.
LVM2: administración de volúmenes lógicos en Linux
Introducción
LVM2 es un administrador de volúmenes lógicos desarrollado para el kernel de Linux, compatible con su predecesor LVM1. En la actualidad, LVM está disponible en la mayoría de los sistemas Linux para utilizarlo al momento de la instalación. De hecho, sistemas como Fedora utilizan LVM si se los particiona como lo sugiere el instalador por defecto.
La primer ventaja fundamental de LVM es que nos quita el inconveniente de dimensionar exactamente las particiones tal cuál las necesitaremos, encontrándonos luego con que el esquema de particionamiento escogido no es el más adecuado. Este caso es muy fácil verlo con un ejemplo.
Se tiene un disco de 40G (pequeño para los tamaños actuales, lo reconozco, pero sirve para el ejemplo). Se desea instalar Linux allí entonces se decide particionarlo de la siguiente manera:
/boot 200M / 4G swap 1G /home 34G
El problema al que nos enfrentamos en este caso (me ha ocurrido en alguna oportunidad) es quedarnos sin espacio en alguna partición y tener lugar de sobra en otra. Por ejemplo, supongamos que se llena el disco raíz y sin embargo tenemos aún 14G libres en /home. Eso representa una situación donde se hace un uso ineficiente del espacio en disco, además de un problema. La solución más obvia en este caso es hacer algún link simbólico apuntando a algún lugar de /home, pero es una solución bastante mala.
Con LVM, la solución a este problema es trivial, dado que se podría simplemente achicar la partición que contiene /home y aumentar luego el espacio asignado al directorio raíz.
Características de LVM2
LVM2 cuenta, básicamente, con las siguientes funcionalidades.
- Redimensión de grupos de volúmenes y volúmenes lógicos en línea.
- Crear instantáneas (snapshots) de lecturea/escritura del sistema de archivos.
- Constituir los volúmenes lógicos separados en los diferentes volúmenes físicos, de manera similar que RAID 0.
- Mover los volúmenes lógicos entre los diferentes volúmenes físicos.
Conceptos básicos de LVM
Para entender cómo funciona LVM es necesario conocer algunos conceptos elementales, que son:
- Volumen físico (PV): un PV es un disco rígido, una partición o un RAID.
- Volumen lógico (LV): un LV es el equivalente a una partición tradicional.
- Grupo de volúmenes (VG): un grupo de volúmenes reúne uno o más PVs. Los PVs pueden comenzar a utilizarse en LVM recién cuando pasan a formar parte de un VG.
- Physical extent (PE): un PE es una porción de cada volumen físico, de tamaño fijo. Un volumen físico se divide en mútiples PEs del mismo tamaño.
- Logical extent (LE): un LE es una porción de cada volumen lógico, de tamaño fijo. Un volumen lógico se divide en mútiples LEs del mismo tamaño.
- Device mapper: es un framework genérico del kernel de Linux que permite realizar un mapeo de un dispositivo de bloques a otro. Es la herramienta fundamental en la que se basa LVM para hacer el mapeo de los dispositivos virtuales con los dispositivos físicos.
Conclusión
LVM es un sistema muy interesante para utilizar ya sea en sistemas pequeños como en sistemas con muchos discos y esquemas complejos de particionamiento. Por su flexibilidad y sus capacidades puede reducir mucho el trabajo de mantenimiento de los equipos y cualquier cambio a nivel de almacenamiento.
En un próximo post explicaré cómo trabajar con LVM, desde la creación de los PVs, VGs y LVs, cómo redimensionarlos y eliminarlos e, incluso, cómo trabajar con las instantáneas.
Equivalencias entre DPKG/RPM y APT/YUM
Las distribuciones basadas en Red Hat usan rpm como el formato de sus paquetes binarios y rpm / yum para administrarlos. Por otro lado, las basadas en debian usan deb y dpkg / apt-get. En la siguiente tabla presento las equivalencias para los usuarios que estén acostumbrado a uno de ellos y se muevan al otro.
Comparación entre dpkg y rpm
| DPKG | RPM | Descripción |
| dpkg -Gi paquete(s).deb | rpm -Uvh packages(s).rpm | Instalar/Upgradear archivo(s) del/de los paquete(s) |
| dpkg -r paquete | rpm -e paquete | Eliminar paquete |
| dpkg -l *palabra* | rpm -qa *palabra* | Mostrar todos los paquetes cuyo nombre contenga “palabra” |
| dpkg -l paquete | rpm -q paquete | Mostrar la versión del paquete instalada |
| dpkg -s paquete | rpm -q -i paquete | Mostrar todos los metadatos del paquete |
| dpkg -I paquete.deb | rpm -q -i -p paquete.rpm | Mostrar todos los metadatos de los archivos del paquete |
| dpkg -S /path/archivo | rpm -q -f /path/archivo | A que paquete pertenece el archivo |
| dpkg -L paquete | rpm -q -l paquete | Lista dónde se instalaron los archivos |
| dpkg -c paquete.deb | rpm -q -l -p paquete.rpm | Lista dónde los archivos serían instalados |
| dpkg -x paquete.deb | cpio -id | Extrae los archivos del paquete al directorio actual |
| dpkg –purge –dry-run paquete | rpm -q –whatrequires paquete | Lista los paquetes que requiere paquete (ver también whatrequires) |
Comparación entre apt-get y yum
| APT-GET | YUM | Descripción |
| apt-get dist-upgrade | yum update [lista de paquetes] | Upgradea todos los paquetes del sistema (en el caso de yum se puede especificar sólo algunos) |
| apt-get install | yum install | Instala la última versión del/de los paquete(s) |
| apt-get remove | yum remove | Elimina los paquetes del sistema |
| apt-cache list [lista de paquetes] | yum list [lista de paquetes] | Lista los paquetes disponibles en los repositorios |
Dpkg: el administrador de paquetes de Debian
Las diferentes distribuciones de Linux suelen incluir un software específico para administrar los paquetes del sistema. En el caso de Debian y sus derivados (como Ubuntu) se trata del popular apt-get y de dpkg. Este último se controla por medio de la línea de comandos o, incluso, utilizando interfaces gráficas. Nosotros veremos el primer caso.
Dpkg permite administrar, construir, instalar y remover paquetes del sistema. Para llevar a cabo su tarea mantiene cierta información sobre los paquetes disponibles que son su estado, el estado de selección y sus flags. En el caso de los estados pueden alterarse manualmente mediante un comando.
La tabla de paquetes que mantiene dpkg se vería como la siguiente:
| PAQUETE 1 | ESTADO | ESTADO DE SELECCION | FLAGS |
| PAQUETE 2 | ESTADO | ESTADO DE SELECCION | FLAGS |
| PAQUETE … | ESTADO | ESTADO DE SELECCION | FLAGS |
| PAQUETE N | ESTADO | ESTADO DE SELECCION | FLAGS |
El estado representa precisamente en qué estado se encuentra en el sistema. Algunos estados disponibles hasta la versión actual son:
| installed | Instalado. |
| not-installed | No fue instalado. |
| config-files | Sólo existe la configuración del paquete en el sistema. |
| unpacked | Sólo ha sido desempaquetado pero no configurado. |
| half-installed | La instalación había comenzado pero no fue completada por alguna razón. |
| half-configured | Se desempaquetó y la configuración había empezado pero finalizó por alguna razón. |
| triggers-awaited | Está esperando de alguna activación. |
| triggers-pending | El paquete ha sido activado. |
El estado de la selección representa la acción a realizar sobre el paquete en cuestión. Los mismos pueden ser:
| install | El paquete fue seleccionado para instalar. |
| hold | Se marcó en espera y no va a ser manipulado por dpkg. |
| deinstall | El paquete es seleccionado para su desinstalación aunque se mantendrán los archivos de configuración. |
| purge | El paquete es seleccionado para su desinstalación, incluyendo sus archivos de configuración. |
Los flags son banderas o etiquetas que avisan sobre el estado de un paquete. Por ejemplo, si el flag reinst-required está activado significa que el paquete necesita de una reinstalación.
