Capítulo 12. Administración avanzada

Este capítulo vuelve sobre algunos aspectos que ya se han descripto anteriormente con una perspectiva diferente: en lugar de instalar un único equipo vamos a estudiar sistemas de despliegue masivo; en lugar de crear volúmenes RAID o LVM durante la instalación, vamos a aprender a hacerlo a mano para que posteriormente podamos revisar nuestras elecciones iniciales. Por último veremos herramientas de monitorización y técnicas de virtualización. Como consecuencia de lo anterior, este capítulo se dirige más a administradores profesionales y no tanto a personas responsables únicamente de su red doméstica.

12.1. RAID y LVM

El Capítulo 4, Instalación presentaba estas tecnologías desde el punto de vista del instalador y cómo éste las integra para hacer sencillo su despliegue desde el comienzo. Después de la instalación inicial, un administrador debe ser capaz de gestionar las cambiantes necesidades de espacio sin tener que recurrir a una reinstalación. Por lo tanto necesita dominar las herramientas necesarias para manipular volúmenes RAID y LVM.

Tanto RAID como LVM son técnicas para abstraer los volúmenes montados de sus correspondientes dispositivos físicos (discos duros reales o particiones de los mismos). El primero protege los datos contra fallos de hardware agregando redundancia mientras que el segundo hace más flexible la gestión de los volúmenes y los independiza del tamaño real de los discos subyacentes. En ambos casos se crean nuevos dispositivos de bloques en el sistema que pueden ser utilizados tanto para crear sistemas de archivos como espacios de intercambio sin necesidad de que se asocien a un disco físico concreto. RAID y LVM tienen orígenes bastante diferentes pero su funcionalidad a veces se solapa, por lo que a menudo se mencionan juntos.

PERSPECTIVA Btrfs combina LVM y RAID

Mientras que LVM y RAID son dos subsistemas diferenciados del núcleo que se interponen entre los dispositivos de bloques de disco y sus sistemas de archivos, btrfs es un nuevo sistema de archivos, desarrollado originalmente por Oracle, que combina las características de LVM, RAID y muchas más. Es funcional en su mayor parte y, a pesar de estar todavía etiquetado como «experimental» porque su desarrollo aún está incompleto (algunas características todavía no están implementadas), se conocen experiencas de uso en entornos reales.

→ http://btrfs.wiki.kernel.org/

Entre las características más notables está el poder tomar una instantánea del sistema de archivos en cualquier momento. Esta copia instantánea no utiliza inicialmente espacio en el disco, y sólo se dupica aquella información que es modificada en alguna de las copias. Este sistema de archivos también gestiona de forma transparente la compresión de archivos y hace sumas de verificación para garantizar la integridad de toda la información almacenada.

Tanto en el caso de RAID como en el de LVM, el núcleo proporciona un archivo de dispositivo de bloques similar a los que corresponden a un disco duro o una partición. Cuando una aplicación u otra parte del núcleo necesita acceder a un bloque de estos dispositivos, el subsistema apropiado canaliza el bloque a la capa física apropiada. Dependiendo de la configuración este bloque podría estar almacenado en uno o varios discos, y su localización puede no estar directamente relacionada con la ubicación del bloque en el dispositivo lógico.

12.1.1. RAID por software

RAID significa array redundante de discos independientes («Redundant Array of Independent Disks»). El objetivo de este sistema es evitar pérdida de datos en caso que falle un disco duro. El principio general es bastante simple: se almacenan los datos en varios discos físicos en lugar de sólo uno, con un nivel de redundancia configurable. Dependiendo de esta cantidad de redundancia, y aún en caso de fallo inesperado del disco, se puede reconstruir los datos sin pérdida desde los discos restantes.

Se puede implementar RAID tanto con hardware dedicado (módulos RAID integrados en las tarjetas controladoras SCSI o SATA) o por abstracción de software (el núcleo). Ya sea por hardware o software, un sistema RAID con suficiente redundancia puede mantenerse operativo de forma transparente cuando falle un disco; las capas superiores (las aplicaciones) inclusive pueden seguir accediendo a los datos a pesar del fallo. Por supuesto, este «modo degradado» puede tener un impacto en el rendimiento y se reduce la reduncancia, por lo que otro fallo de disco puede llevar a la pérdida de datos. En la práctica por lo tanto, uno intentará estar en este modo degradado sólo el tiempo que tome reemplazar el disco fallado. Una vez que instale el nuevo disco, el sistema RAID puede reconstruir los datos necesarios para volver a un modo seguro. Las aplicaciones no notarán cambio alguno, además de la posible disminución en la velocidad de acceso, mientras que el array esté en modo degradado o durante la fase de reconstrucción.

Cuando se implementa RAID con hardware, generalmente se lo configura desde la herramienta de configuración del BIOS y el núcleo considerará el array RAID como un solo disco que funcionará como un disco físico estándar, pero el nombre del dispositivo podría ser diferente. Por ejemplo, el núcleo en Squeeze nombra a algunos arrays RAID por hardware disponibles como /dev/cciss/c0d0; el núcleo en Wheezy cambió este nombre al más natural /dev/sda, pero otros controladores RAID podrían tener un comportamiento diferente.

En este libro sólo nos enfocaremos en RAID por software.

12.1.1.1. Diferentes niveles de RAID

RAID no es sólo un sistema sino un rango de sistemas identificados por sus niveles, los cuales se diferencian por su disposición y la cantidad de redundancia que proveen. Mientras más redundantes, más a prueba de fallos serán ya que el sistema podrá seguir funcionando con más discos fallados. Por el otro lado, el espacio utilizable disminuye dado un conjunto de discos; visto de otra forma, necesitará más discos para almacenar una cantidad de datos particular.

RAID lineal: Aún cuando el subsistema RAID del núcleo permite crear «RAID lineal», esto no es RAID propiamente ya que esta configuración no provee redundancia alguna. El núcleo simplemente agrupa varios discos de punta a punta y provee el volúmen agrupado como un solo disco virtual (un dispositivo de bloque). Esa es toda su función. Rara vez se utiliza únicamente esta configuración (revise más adelante las excepciones), especialmente debido a que la falta de redundancia significa que el fallo de un disco hará que todo el grupo, y por lo tanto todos los datos, no estén disponibles.
RAID-0: Este nivel tampoco provee redundancia, pero los discos no están simplemente agrupados uno después del otro: están divididos en tiras («stripes»), y los bloques en el dispositivo virtual son almacenados en tiras de discos físicos alternados. En una configuración RAID-0 de dos discos, por ejemplo, los bloques pares del dispositivo virtual serán almacenados en el primer disco físico mientras que los bloques impares estarán en el segundo disco físico.
Este sistema no intenta aumentar la confiabilidad ya que (como en el caso lineal) se compromete la disponibilidad de todos los datos tan pronto como falle un disco, pero sí aumenta el rendimiento: durante el acceso secuencial a grandes cantidades de datos contiguos, el núcleo podrá leer de (o escribir a) ambos discos en paralelo, lo que aumentará la tasa de transferencia de datos. Sin embargo, está disminuyendo el uso de RAID-0 en favor de LVM (revise más adelante).
RAID-1: Este nivel, también conocido como «espejado RAID» («mirroring») es la configuración más simple y la más utilizada. En su forma estándar, utiliza dos discos físicos del mismo tamaño y provee un volúmen lógico nuevamente del mismo tamaño. Se almacenan los datos de forma idéntica en ambos discos, de ahí el apodo «espejo» («mirror»). Cuando falla un disco, los datos continúan disponibles en el otro. Para datos realmente críticos, obviamente, RAID-1 puede configurarse con más de dos discos, con un impacto directo en la relación entre el costo del hardware y el espacio disponible para datos útiles.
NOTA Discos y tamaños de «cluster»
Si configura en espejo dos discos de diferentes tamaños, el más grande no será completamente utilizado ya que contendrá los mismos datos que el más paqueño y nada más. Por lo tanto, el espacio útil que provee un volúmen RAID-1 es el tamaño del menor de los discos en el array. Esto también aplica a volúmenes RAID de mayor nivel RAID, aún cuando la redundancia se almacene de forma diferente.
Por lo tanto es importante, cuando configure arrays RAID (a excepción de RAID-0 y «RAID lineal») sólo agrupar discos de tamaño idéntico, o muy similares, para evitar desperdiciar recursos.
NOTA Discos libres
Los niveles RAID que incluyen redundancia permiten asignar a un array más discos que los necesarios. Los discos adicionales son utilizados como repuestos cuando falla alguno de los discos principales. Por ejemplo, en un espejo de dos discos más uno libre, si falla uno de los primeros discos el núcleo automáticamente (e inmediatamente) reconstruirá el espejo utilizando el disco libre para continuar asegurando la redundancia luego del tiempo de reconstrucción. Puede utilizar esta característica como otra barrera de seguridad para datos críticos.
Es normal preguntarse porqué esto es mejor que simplemente configurar el espejo con tres discos desde el comienzo. La ventaja de la configuración con un «disco libre» es que puede compartir este último entre varios volúmenes RAID. Por ejemplo, uno puede tener tres volúmenes en espejo asegurando redundancia en caso que falle un disco con sólo siete discos (tres pares más un disco libre compartido), en lugar de los nueve discos que necesitaría para configurar tres tríos de discos.
Este nivel de RAID, aunque costoso (debido a que sólo es útil la mitad del espacio de almacenamiento en el mejor de los casos) es muy utilizado en la práctica. Es simple de entender y permite respaldos muy simples, como ambos discos tienen el mismo contenido puede extraer temporalmente uno de ellos sin impactar el funcionamiento del sistema. Usualmente aumenta el rendimiento de lectura ya que el núcleo puede leer la mitad de los datos de cada disco en paralelo, mientras que el rendimiento de escritura no se ve afectado muy seriamente. En el caso de un array RAID-1 de N discos, los datos continuarán disponibles en caso que fallen N-1 discos.
RAID-4: Este nivel de RAID, que no es muy utilizado, utiliza N discos para almacenar datos útiles y un disco extra para almacenar información de redundancia. Si falla este disco, el sistema puede reconstruir su contenido de los otros N. Si uno de los N discos de datos falla, la combinación de los demás N-1 discos junto con el disco de «paridad» contiene suficiente información para reconstruir los datos necesarios.
RAID-4 no es demasiado costoso ya que sólo implica un aumento de uno-en-N en los costos y no tiene un impacto significativo en el rendimiento de lectura, pero se reduce la velocidad de escritura. Lo que es más, debido a que escribir en cualquier disco involucra escribir en el disco de paridad este último recibirá muchas más escrituras que los demás y, como consecuencia, podría reducir su tiempo de vida dramáticamente. Los datos en un array RAID-4 están seguro sólo contra el fallo de un disco (de los N+1).
RAID-5: RAID-5 soluciona el problema de asimetría de RAID-4: los bloques de paridad están distribuidos en todos los N+1 discos, ninguno de los discos tiene un rol particular.
El rendimiento de lectura y escritura es idéntica a la de RAID-4. Aquí también el sistema continuará su funcionamiento con el fallo de hasta un disco (de los N+1), pero no más.
RAID-6: Se puede considerar a RAID-6 como una extensión de RAID-5, donde cada serie de N bloques poseen dos bloques de redundancia, y cada serie de N+2 bloques está distribuida en N+2 discos.
Este nivel de RAID es ligeramente más costoso que los dos anteriores, pero agrega seguridad adicional ya que pueden fallar hasta dos discos (de N+2) sin comprometer la disponibilidad de los datos. Por el otro lado, las operaciones de escritura ahora deben escribir un bloque de datos y dos bloques de redundancia, lo que lo hace aún más lento.
RAID-1+0: Estrictamente hablando, este no es un nivel RAID sino la combinación de dos agrupaciones RAID. Comience con 2×N discos, configúrelos en pares de N volúmenes RAID-1; y luego agrupe estos N volúmenes en sólo uno, ya sea con «RAID lineal» o (cada vez más) LVM. Este último caso va más allá de RAID puro, pero no hay problemas con ello.
RAID-1+o puede sobrevivir el fallo de varios discos, hasta N en el array de 2×N antes descripto, siempre que continúe trabajando al menos uno de los discos en cada par RAID-1.
YENDO MÁS ALLÁ RAID-10
Generalmente se considera a RAID-10 como sinónimo de RAID-1+0, pero algo específico de Linux lo hace en realidad una generalización. Esta configuración permite un sistema en el que cada bloque está almacenado en dos discos diferentes, aún con una cantidad impar de discos, con las copias distribuidas en un modelo configurable.
El rendimiento variará dependiendo del modelo de reparto y el nivel de redundancia que seleccione, así como también de la carga en el volúmen lógico.

Obviamente, seleccionará el nivel RAID según las limitaciones y requisitos de cada aplicación. Sepa que un mismo equipo puede tener varios arrays RAID distintos con diferentes configuraciones.

12.1.1.2. Configuración de RAID

Para configurar un volúmen RAID necesitará el paquete mdamd ; éste provee el programa mdadm, que permite crear y modificar arrays RAID, así como también scripts y herramientas que lo integran al resto del sistema, incluyendo el sistema de monitorización.

Nuestro ejemplo será un servidor con una cantidad de discos, algunos que ya están utilizados, y el resto se encuentran disponibles para configurar RAID. Inicialmente tendremos los siguientes discos y particiones:

el disco sdb, de 4 GB, completamente disponible;
el disco sdc, de 4 GB, también completamente disponible;
en el disco sdd hay disponible una única partición sdd2 (de alrededor de 4 GB);
finalmente, un disco sde, también de 4 GB, completamente disponible.

Utilizaremos estos elementos físicos para crear dos volúmenes, un RAID-0 y un espejo (RAID-1). Comencemos con el volúmen RAID-0:

# mdadm --create /dev/md0 --level=0 --raid-devices=2 /dev/sdb /dev/sdc
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md0 started.
# mdadm --query /dev/md0
/dev/md0: 8.00GiB raid0 2 devices, 0 spares. Use mdadm --detail for more detail.
# mdadm --detail /dev/md0
/dev/md0:
        Version : 1.2
  Creation Time : Thu Jan 17 15:56:55 2013
     Raid Level : raid0
     Array Size : 8387584 (8.00 GiB 8.59 GB)
   Raid Devices : 2
  Total Devices : 2
    Persistence : Superblock is persistent

    Update Time : Thu Jan 17 15:56:55 2013
          State : clean 
 Active Devices : 2
Working Devices : 2
 Failed Devices : 0
  Spare Devices : 0

     Chunk Size : 512K

           Name : mirwiz:0  (local to host mirwiz)
           UUID : bb085b35:28e821bd:20d697c9:650152bb
         Events : 0

    Number   Major   Minor   RaidDevice State
       0       8       16        0      active sync   /dev/sdb
       1       8       32        1      active sync   /dev/sdc
# mkfs.ext4 /dev/md0
mke2fs 1.42.5 (29-Jul-2012)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=128 blocks, Stripe width=256 blocks
524288 inodes, 2096896 blocks
104844 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=2147483648
64 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks: 
       32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632

Allocating group tables: done                            
Writing inode tables: done                            
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done 
# mkdir /srv/raid-0
# mount /dev/md0 /srv/raid-0
# df -h /srv/raid-0
Filesystem      Size  Used Avail Use% Mounted on
/dev/md0        7.9G  146M  7.4G   2% /srv/raid-0

La orden mdadm --create necesita varios parámetros: el nombre del volúmen a crear (/dev/md*, donde MD es acrónimo de múltiples dispositivos — «Multiple Device»), el nivel RAID, la cantidad de discos (que es obligatorio a pesar de que sea sólo importante con RAID-1 y superior), y los dispositivos físicos a utilizar. Una vez que creó el dispositivo, podemos utilizarlo como si fuese una partición normal, crear un sistema de archivos en él, montarlo, etc. Sepa que el que creáramos un volúmen RAID-0 como md0 es sólo una coincidencia, la numeración del array no tiene correlación alguna con la cantidad de redundancia elegida. También es posible crear arrays RAID con nombre si se proveen los parámetros correctos a mdadm, como /dev/md/linear en lugar de /dev/md0.

Crear un RAID-1 es similar, las diferencias sólo son notables luego:

# mdadm --create /dev/md1 --level=1 --raid-devices=2 /dev/sdd2 /dev/sde
mdadm: Note: this array has metadata at the start and
    may not be suitable as a boot device.  If you plan to
    store '/boot' on this device please ensure that
    your boot-loader understands md/v1.x metadata, or use
    --metadata=0.90
mdadm: largest drive (/dev/sdd2) exceeds size (4192192K) by more than 1%
Continue creating array? y
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md1 started.
# mdadm --query /dev/md1
/dev/md1: 4.00GiB raid1 2 devices, 0 spares. Use mdadm --detail for more detail.
# mdadm --detail /dev/md1
/dev/md1:
        Version : 1.2
  Creation Time : Thu Jan 17 16:13:04 2013
     Raid Level : raid1
     Array Size : 4192192 (4.00 GiB 4.29 GB)
  Used Dev Size : 4192192 (4.00 GiB 4.29 GB)
   Raid Devices : 2
  Total Devices : 2
    Persistence : Superblock is persistent

    Update Time : Thu Jan 17 16:13:04 2013
          State : clean, resyncing (PENDING) 
 Active Devices : 2
Working Devices : 2
 Failed Devices : 0
  Spare Devices : 0

           Name : mirwiz:1  (local to host mirwiz)
           UUID : 6ec558ca:0c2c04a0:19bca283:95f67464
         Events : 0

    Number   Major   Minor   RaidDevice State
       0       8       50        0      active sync   /dev/sdd2
       1       8       64        1      active sync   /dev/sde
# mdadm --detail /dev/md1
/dev/md1:
[...]
          State : clean
[...]

Son necesarios algunos comentarios. Primero, mdadm está al tanto que los elementos físicos tiene diferentes tamaños; se necesita confirmar ya que esto implicará que perderá espacio en el elemento más grande.

Lo que es más importante, revise el estado del espejo. El estado normal de un espejo RAID es que ambos discos tengan el mismo contenido. Sin embargo, nada garantiza que este sea el caso cuando se crea el volumen. Por lo tanto, el subsistema RAID dará esta garantía por su cuenta y, tan pronto como se crea el dispositivo RAID, habrá una fase de sincronización. Luego de un tiempo (cuánto exactamente dependerá del tamaño de los discos…), el array RAID cambiará al estado «active» (activo). Sepa que durante esta fase de reconstrucción el espejo se encuentra en modo degradado y no se asegura redundancia. Si falla un disco durante esta ventana de riesgo podrá perder toda la información. Sin embargo, rara vez se almacenan grandes cantidades de datos críticos en un array RAID creado recientemente antes de su sincronización inicial. Sepa que aún en modo degradado puede utilizar /dev/md1 y puede crear en él un sistema de archivos así como también copiar datos.

SUGERENCIA Inicio de un espejo en modo degradado

A veces no se encuentran inmediatamente disponibles dos discos cuando uno desea iniciar un espejo RAID-1, por ejemplo porque uno de los discos que uno planea utilizar está siendo utilizado y contiene los datos que uno quiere almacenar en el array. En estas situaciones, es posible crear intencionalmente un array RAID-1 degradado si se utiliza missing en lugar del archivo del dispositivo como uno de los parámetros de mdadm. Una vez que copió los datos al «espejo», puede agregar el disco antiguo al array. Luego ocurrirá la fase de sincronización, proveyendo la redundancia que deseábamos en primer lugar.

SUGERENCIA Configuración de un espejo sin sincronización

Usualmente creará volúmenes RAID-1 para ser utilizados como un disco nuevo, generalmente considerados en blanco. El contenido inicial del disco no es realmente relevante, ya que uno sólo necesita saber que se podrán acceder luego a los datos escritos luego que creamos el volumen, en particular: el sistema de archivos.

Por lo tanto, uno podría preguntarse el sentido de sincronizar ambos discos al momento de crearlo. ¿Porqué importa si el contenido es idéntico en las zonas del volúmen que sabemos sólo serán accedidas luego que escribamos en ellas?

Afortunadamente, puede evitar esta fase de sincronización con la opción --assume-clean de mdadm. Sin embargo, esta opción puede llevar a sorpresas en casos en el que se lean los datos iniciales (por ejemplo, si ya existe un sistema de archivos en los discos físicos), lo que explica porqué no es activada de forma predeterminada.

Veamos ahora qué sucede cuando falla uno de los elementos del array RAID-1. mdadm, su opción --fail en particular, permite simular tal fallo:

# mdadm /dev/md1 --fail /dev/sde
mdadm: set /dev/sde faulty in /dev/md1
# mdadm --detail /dev/md1
/dev/md1:
[...]
    Update Time : Thu Jan 17 16:14:09 2013
          State : active, degraded 
 Active Devices : 1
Working Devices : 1
 Failed Devices : 1
  Spare Devices : 0

           Name : mirwiz:1  (local to host mirwiz)
           UUID : 6ec558ca:0c2c04a0:19bca283:95f67464
         Events : 19

    Number   Major   Minor   RaidDevice State
       0       8       50        0      active sync   /dev/sdd2
       1       0        0        1      removed

       1       8       64        -      faulty spare   /dev/sde

El contenido del volúmen continúa accesible (y, si está montado, las aplicaciones no lo notarán), pero ya no se asegura la seguridad de los datos: en caso que falle el disco sdd, perderá los datos. Deseamos evitar este riesgo, por lo que reemplazaremos el disco fallido con uno nuevo, sdf:

# mdadm /dev/md1 --add /dev/sdi
mdadm: added /dev/sdi
# mdadm --detail /dev/md1
/dev/md1:
[...]
   Raid Devices : 2
  Total Devices : 3
    Persistence : Superblock is persistent

    Update Time : Thu Sep 30 15:52:29 2010
          State : active, degraded, recovering
 Active Devices : 1
Working Devices : 2
 Failed Devices : 1
  Spare Devices : 1

 Rebuild Status : 45% complete

           Name : squeeze:1  (local to host squeeze)
           UUID : 20a8419b:41612750:b9171cfe:00d9a432
         Events : 53

    Number   Major   Minor   RaidDevice State
       0       8       98        0      active sync   /dev/sdg2
       3       8      128        1      spare rebuilding   /dev/sdi

       2       8      112        -      faulty spare   /dev/sdh
# [...]
[...]
# mdadm --detail /dev/md1
/dev/md1:
[...]
    Update Time : Thu Sep 30 15:52:35 2010
          State : active
 Active Devices : 2
Working Devices : 2
 Failed Devices : 1
  Spare Devices : 0

           Name : squeeze:1  (local to host squeeze)
           UUID : 20a8419b:41612750:b9171cfe:00d9a432
         Events : 71

    Number   Major   Minor   RaidDevice State
       0       8       98        0      active sync   /dev/sdg2
       1       8      128        1      active sync   /dev/sdi

       2       8      112        -      faulty spare   /dev/sdh

Nuevamente, el núcleo automáticamente inicia una fase de reconstruciión durante la que el volúmen, aunque continúa disponible, se encuentra en modo degradado. Una vez finalizada la reconstrucción, el array RAID volverá a estado normal. Uno puede indicarle al sistema que eliminará el disco sde del array, para obtener un espejo RAID clásico en dos discos:

# mdadm /dev/md1 --remove /dev/sde
mdadm: hot removed /dev/sde from /dev/md1
# mdadm --detail /dev/md1
/dev/md1:
[...]
    Number   Major   Minor   RaidDevice State
       0       8       50        0      active sync   /dev/sdd2
       2       8       80        1      active sync   /dev/sdf

De allí en adelante, puede quitar físicamente el dispositivo la próxima vez que se apague el servidor, o inclusive quitarlo en caliente si la configuración del hardware lo permite. Tales configuraciones incluyen algunos controladores SCSI, la mayoría de los discos SATA y discos externos USB o Firewire.

12.1.1.3. Respaldos de la configuración

La mayoría de los metadatos de los volúmenes RAID se almacenan directamente en los discos que componen dichos arrays, de esa forma el núcleo puede detectar el array y sus componentes y ensamblarlos automáticamente cuando inicia el sistema. Sin embargo, se recomienda respaldar esta configuración ya que esta detección no es infalible y, como no podía ser de otra forma, fallará precisamente en las circunstancias más sensibles. En nuestro ejemplo, si el fallo del disco sde hubiese sido real (en lugar de similada) y se hubiese reiniciado el sistema sin quitar el disco sde, éste podría ser utilizado nuevamente debido a haber sido probado durante el reinicio. El núcleo entonces tendría tres elementos físicos, cada uno de los cuales indica poseer la mitad del mismo volumen RAID. Otra fuente de confusión es cuando se consolidan en un servidor volúmenes RAID de dos servidores. Si los arrays funcionaban normalmente antes de quitar los discos, el núcleo podrá detectarlos y reconstruir los pares correctamente; pero si los discos mudados se encontraban agrupados como md1 en el antiguo servidor pero el nuevo servidor ya posee un grupo md1, se modificará el nombre de uno de los espejos.

Por lo tanto es importante respaldar la configuración, aunque sea tan sólo como referencia. La forma estándar de realizarlo es editar el archivo /etc/mdadm/mdadm.conf, a continuación un ejemplo del mismo:

Ejemplo 12.1. Archivo de configuración de mdadm

# mdadm.conf
#
# Revise mdadm.conf(5) para más información sobre este archivo.
#

# de forma predeterminada, buscar superbloques MD en todas las
# particiones (/proc/partitions) y contenedores. Alternativamente,
# especifique los dispositivos a escanear, utilice comodines si
# es necesario.
DEVICE /dev/sd*

# crear dispositivos automáticamente con permisos estándar en Debian
CREATE owner=root group=disk mode=0660 auto=yes

# etiquetar automáticamente arrays como locales al sistema
HOMEHOST <system>

# indicarle al demonio de monitorización que envíe correos de alerta
MAILADDR root

# definiciones para arrays MD existentes
ARRAY /dev/md0 metadata=1.2 name=mirwiz:0 UUID=bb085b35:28e821bd:20d697c9:650152bb
ARRAY /dev/md1 metadata=1.2 name=mirwiz:1 UUID=6ec558ca:0c2c04a0:19bca283:95f67464

# Se autogeneró esta configuración el día Jue 17 de Ene 2013 16:21:01 +0100
# con mkconf 3.2.5-3

Uno de los detalles más útiles es la opción DEVICE, que enumera los dispositivos en los que el sistema buscará componentes de un volumen RAID automáticamente cuando inicia. En nuestro ejemplo, reemplazamos el valor predeterminado, partitions containers, con una lista explícita de archivos de dispositivos, ya que para algunos volúmenes elegimos utilizar discos enteros y no sólo particiones.

Las dos últimas líneas en nuestro ejemplo son las que le permiten al núcleo seleccionar de forma segura qué número de volumen asignar a qué array. Los metadatos almacenados en los mismos discos son suficientes para reconstruir los volúmenes, pero no para determinar el número del mismo (y el nombre del dispositivo /dev/md* correspondiente).

Afortunadamente, puede generar estas líneas automáticamente:

# mdadm --misc --detail --brief /dev/md?
ARRAY /dev/md0 metadata=1.2 name=mirwiz:0 UUID=bb085b35:28e821bd:20d697c9:650152bb
ARRAY /dev/md1 metadata=1.2 name=mirwiz:1 UUID=6ec558ca:0c2c04a0:19bca283:95f67464

El contenido de estas dos últimas líneas no depende de la lista de discos incluidos en el volumen. Por lo tanto, no es necesario regenerar estas líneas cuando reemplace un disco fallido con uno nuevo. Por el otro lado, debe asegurarse de actualizar el archivo cuando cree o elimine un array RAID.

12.1.2. LVM

LVM, el gestor de volúmenes lógicos («Logical Volume Manager»), es otra forma de abstraer volúmenes lógicos de su soporte físico, que se enfoca en mayor flexibilidad en lugar de aumentar confiabilidad. LVM permite modificar un volumen lógico de forma transparente a las aplicaciones; por ejemplo, es posible agregar nuevos discos, migrar sus datos y eliminar discos antiguos sin desmontar el volumen.

12.1.2.1. Conceptos de LVM

Se consigue esta flexibilidad con un nivel de abstracción que incluye tres conceptos.

Primero, el PV (volumen físico: «Physical Volume») es la entidad más cercana al hardware: pueden ser particiones en un disco, un disco completo o inclusive cualquier dispositivo de bloque (también un array RAID, por ejemplo). Sepa que cuando configura un elemento físico como PV para LVM, sólo debe acceder al mismo a través de LVM, de lo contrario confundirá al sistema.

Puede agrupar una cantidad de PVs en un VG (grupo de volúmenes: «Volume Group»), lo que puede compararse con discos virtuales y extensibles. Los VGs son abstractos y no aparecerán como un archivo de dispositivo en la jerarquía /dev, por lo que no hay riesgo de utilizarlos directamente.

El tercer tipo de objeto es el LV (volúmen lógico: «Logical Volume»), que es una porción de un VG; si continuamos con la analogía de un VG-como-disco, un LV se compara a una partición. El LV será un dispositivo de bloque que tendrá un elemento en /dev y puede utilizarlo como lo haría con cualquier partición física (usualmente, almacenar un sistema de archivos o espacio de intercambio).

Lo importante es que la división de un VG en varios LVs es completamente independiente de sus componentes físicos (los PVs). Puede dividir un VG con un sólo componente físico (un disco por ejemplo) en una docena de volúmenes lógicos; similarmente, un VG puede utilizar varios discos físicos y aparecer como sólo un volúmen lógico grande. La única limitación es que, obviamente, el tamaño total asignado a un LV no puede ser mayor que la capacidad total de los PVs en el grupo de volúmenes.

Generalmente tiene sentido, sin embargo, mantener el mismo tipo de homogeneidad entre los componentes físicos de un VG y dividir el VG en volúmenes lógicos que tendrán patrones de uso similares. Por ejemplo, si el hardware disponible incluye discos rápidos y discos lentos, podría agrupar los discos rápidos en un VG y los lentos en otro; puede asignar pedazos del primero a aplicaciones que necesiten acceso rápido a los datos y mantener el segundo para tareas menos exigentes.

En cualquier caso, recuerde que un LV no está asociado especialmente a ningún PV. Es posible influenciar dónde se almacenarán físicamente los datos de un LV, pero esta posibilidad no es necesaria para el uso diario. Por el contrario, cuando evolucionan los componentes físicos de un VG, puede migrar las ubicaciones físicas del almacenamiento que corresponden a un LV particuar (siempre manteniéndose dentro de los PVs asignados al VG por supuesto).

12.1.2.2. Configuración de LVM

Sigamos ahora, paso a paso, el proceso de configuración de LVM para un caso de uso típico: deseamos simplificar una situación compleja de almacenamiento. Situaciones como esta generalmente ocurren luego de una historia larga y complicada de medidas temporales que se acumulan. A modo ilustrativo utilizaremos un servidor en el que las necesidades de almacenamiento cambiaron con el tiempo, lo que culminó en un laberinto de particiones disponibles divididas en varios discos parcialmente utilizados. En términos más concretos, están disponibles las siguientes particiones:

en el disco sdb, una partición sdb2 de 4Gb;
en el disco sdc, una partición sdc3 de 3 GB;
el disco sdd, de 4 GB, completamente disponible;
en el disco sdf, una partición sdf1 de 4 GB y una partición sdf2 de 5GB.

Además, asumiremos que los discos sdb y sdf son más rápidos que los otros dos.

Nuestro objetivo es configurar tres volúmenes lógicos para tres aplicaciones diferentes: un servidor de archivos que necesita 5 GB como espacio de almacenamiento, una base de datos (1 GB) y un poco de espacio para respaldos (12 GB). Los primeros dos necesitan buen rendimiento, pero los respaldos son menos críticos en cuanto a velocidad de acceso. Todas estas limitaciones evitan que simplemente utilicemos particiones; utilizar LVM puede abstraer el tamaño físico de los dispositivos, por lo que el único límite es el espacio total disponible.

El paquete lvm2 y sus dependencias contienen las herramientas necesarias. Después de instalarlos, configurar LVM son tres pasos que coinciden con los tres niveles de conceptos.

Primero, prepararemos los volúmenes físicos utilizando pvcreate:

# pvdisplay
# pvcreate /dev/sdb2
  Writing physical volume data to disk "/dev/sdb2"
  Physical volume "/dev/sdb2" successfully created
# pvdisplay
  "/dev/sdb2" is a new physical volume of "4.00 GiB"
  --- NEW Physical volume ---
  PV Name               /dev/sdb2
  VG Name               
  PV Size               4.00 GiB
  Allocatable           NO
  PE Size               0   
  Total PE              0
  Free PE               0
  Allocated PE          0
  PV UUID               0zuiQQ-j1Oe-P593-4tsN-9FGy-TY0d-Quz31I

# for i in sdc3 sdd sdf1 sdf2 ; do pvcreate /dev/$i ; done
  Writing physical volume data to disk "/dev/sdc3"
  Physical volume "/dev/sdc3" successfully created
  Writing physical volume data to disk "/dev/sdd"
  Physical volume "/dev/sdd" successfully created
  Writing physical volume data to disk "/dev/sdf1"
  Physical volume "/dev/sdf1" successfully created
  Writing physical volume data to disk "/dev/sdf2"
  Physical volume "/dev/sdf2" successfully created
# pvdisplay -C
  PV         VG   Fmt  Attr PSize PFree
  /dev/sdb2       lvm2 a--  4.00g 4.00g
  /dev/sdc3       lvm2 a--  3.09g 3.09g
  /dev/sdd        lvm2 a--  4.00g 4.00g
  /dev/sdf1       lvm2 a--  4.10g 4.10g
  /dev/sdf2       lvm2 a--  5.22g 5.22g

Hasta ahora, todo va bien; sepa que puede configurar un PV en un disco completo así como también en particiones individuales del mismo. Como mostramos, el programa pvdisplay enumera los PVs existentes, con dos formatos de salida posibles.

Ahora agruparemos estos elementos físicos en VGs utilizando vgcreate. Reuniremos PVs de los discos rápidos en el VG vg_critical; el otro VG, vg_normal también incluirá los elementos más lentos.

# vgdisplay
  No volume groups found
# vgcreate vg_critical /dev/sdb2 /dev/sdf1
  Volume group "vg_critical" successfully created
# vgdisplay
  --- Volume group ---
  VG Name               vg_critical
  System ID             
  Format                lvm2
  Metadata Areas        2
  Metadata Sequence No  1
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                0
  Open LV               0
  Max PV                0
  Cur PV                2
  Act PV                2
  VG Size               8.09 GiB
  PE Size               4.00 MiB
  Total PE              2071
  Alloc PE / Size       0 / 0   
  Free  PE / Size       2071 / 8.09 GiB
  VG UUID               bpq7zO-PzPD-R7HW-V8eN-c10c-S32h-f6rKqp

# vgcreate vg_normal /dev/sdc3 /dev/sdd /dev/sdf2
  Volume group "vg_normal" successfully created
# vgdisplay -C
  VG          #PV #LV #SN Attr   VSize  VFree 
  vg_critical   2   0   0 wz--n-  8.09g  8.09g
  vg_normal     3   0   0 wz--n- 12.30g 12.30g

Aquí también los programas son bastante directos (y vgdisplay también propone dos formatos de salida). Sepa que es posible utilizar dos particiones del mismo disco físico en dos VGs diferentes. Además utilizamos el prefijo vg_ para el nombre de nuestros VGs, pero es sólo una convención.

Ahora contamos con dos «discos virtuales», de alrededor 8 GB y 12 GB de tamaño respectivamente. Ahora los repartiremos en «particiones virtuales» (LVs). Esto involucra el programa lvcreate y una sintaxis ligeramente más compleja:

# lvdisplay
# lvcreate -n lv_files -L 5G vg_critical
  Logical volume "lv_files" created
# lvdisplay
  --- Logical volume ---
  LV Path                /dev/vg_critical/lv_files
  LV Name                lv_files
  VG Name                vg_critical
  LV UUID                J3V0oE-cBYO-KyDe-5e0m-3f70-nv0S-kCWbpT
  LV Write Access        read/write
  LV Creation host, time mirwiz, 2013-01-17 17:05:13 +0100
  LV Status              available
  # open                 0
  LV Size                5.00 GiB
  Current LE             1280
  Segments               2
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           253:0

# lvcreate -n lv_base -L 1G vg_critical
  Logical volume "lv_base" created
# lvcreate -n lv_backups -L 12G vg_normal
  Logical volume "lv_backups" created
# lvdisplay -C
  LV         VG          Attr     LSize  Pool Origin Data%  Move Log Copy%  Convert
  lv_base    vg_critical -wi-a---  1.00g                                           
  lv_files   vg_critical -wi-a---  5.00g                                           
  lv_backups vg_normal   -wi-a--- 12.00g

Necesita dos parámetros cuando cree volúmenes lógicos; debe proveerlos a lvcreate como opciones. Especificará el nombre del LV a crear con la opción -n y, usualmente, su tamaño con la opción -L. Por supuesto, también necesitaremos indicarle sobre qué VG trabajar, de allí el último parámetro en la ejecución.

YENDO MÁS ALLÁ Opciones de lvcreate

El programa lvcreate tiene varias opciones que modifican la creación del LV.

Primero describamos la opción -l, con la que puede indicar el tamaño del LV como una cantidad de bloques (en lugar de las unidades «humanas» que utilizamos en el ejemplo). Estos bloques (PEs en términos de LVM, extensiones físicas: «physical extents») son unidades de espacio de almacenamiento contiguo en los PVs, y no pueden dividirse entre LVs. Cuando uno desea definir el espacio de almacenamiento para un LV con cierta precisión, por ejemplo para utilizar todo el espacio disponible, generalmente es preferible utilizar la opción -l en lugar de -L.

También es posible sugerir la ubicación física de un LV para que se almacenen sus extensiones en un PV particular (obviamente limitándose a aquellas asignadas al VG). Dado que sabemos que sdb es más rápido que sdf, desearíamos almacenar lv_base allí si nos interesa darle una ventaja al servidor de base de datos comparado con el servidor de archivos. De esa forma, la orden a ejecutar sería: lvcreate -n lv_base -L 1G vg_critical /dev/sdb2. Sepa que esta ejecución puede fallar si el PV no posee suficientes extensiones libres. En nuestro ejemplo, probablemente deberíamos crear lv_base antes que lv_files para evitar esta situación — o liberar algo de espacio en sdb2 con el programa pvmove.

Una vez que creó los volúmenes lógicos, éstos serán archivos de dispositivos de bloque en /dev/mapper/:

# ls -l /dev/mapper
total 0
crw------T 1 root root 10, 236 Jan 17 16:52 control
lrwxrwxrwx 1 root root       7 Jan 17 17:05 vg_critical-lv_base -> ../dm-1
lrwxrwxrwx 1 root root       7 Jan 17 17:05 vg_critical-lv_files -> ../dm-0
lrwxrwxrwx 1 root root       7 Jan 17 17:05 vg_normal-lv_backups -> ../dm-2
# ls -l /dev/dm-*
brw-rw---T 1 root disk 253, 0 Jan 17 17:05 /dev/dm-0
brw-rw---T 1 root disk 253, 1 Jan 17 17:05 /dev/dm-1
brw-rw---T 1 root disk 253, 2 Jan 17 17:05 /dev/dm-2

NOTA Autodetección de volúmenes LVM

Cuando inicia el equipo, el script /etc/init.d/lvm escanea los dispositivos disponibles; registra con el subsistema LVM a aquellos que fueron inicializados como volúmenes físicos para LVM, agrupa aquellos que pertenecen a grupos de volúmenes e inicializa y hace disponibles los volúmenes lógicos relevantes. Por lo tanto, no es necesario editar archivos de configuración cuando crea o modifica volúmenes LVM.

Sepa, sin embargo, que se respalda la distribución de los elementos de LVM (volúmenes físicos y loǵicos y grupos de volúmenes) en /etc/lvm/backup, lo cual puede ser útil en caso de algún problema (o tan sólo para espiar tras bambalinas).

Para hacer las cosas más sencillas, se crean enlaces simbólicos convenientes en directorios que coinciden con los VGs:

# ls -l /dev/vg_critical
total 0
lrwxrwxrwx 1 root root 7 Jan 17 17:05 lv_base -> ../dm-1
lrwxrwxrwx 1 root root 7 Jan 17 17:05 lv_files -> ../dm-0
# ls -l /dev/vg_normal
total 0
lrwxrwxrwx 1 root root 7 Jan 17 17:05 lv_backups -> ../dm-2

Puede utilizar LVs exactamente de la misma forma que particiones estándar:

# mkfs.ext4 /dev/vg_normal/lv_backups
mke2fs 1.42.5 (29-Jul-2012)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
[...]
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done 
# mkdir /srv/backups
# mount /dev/vg_normal/lv_backups /srv/backups
# df -h /srv/backups
Filesystem                        Size  Used Avail Use% Mounted on
/dev/mapper/vg_normal-lv_backups   12G  158M   12G   2% /srv/backups
# [...]
[...]
# cat /etc/fstab
[...]
/dev/vg_critical/lv_base    /srv/base       ext4
/dev/vg_critical/lv_files   /srv/files      ext4
/dev/vg_normal/lv_backups   /srv/backups    ext4

Desde el punto de vista de las aplicaciones, todas las pequeñas particiones se encuentran abstraídas en un gran volumen de 12 GB con un nombre más amigable.

12.1.2.3. LVM en el tiempo

Aún cuando es conveniente poder agrupar particiones o discos físicos, esta no es la principal ventaja que provee LVM. La flexibilidad que brinda es especialmente notable con el paso del tiempo cuando evolucionan las necesidades. En nuestro ejemplo, supongamos que debemos almacenar nuevos archivos grandes y que el LV dedicado al servidor de archivos es demasiado pequeño para contenerlos. Debido a que no utilizamos todo el espacio disponibleen vg_critical, podemos aumentar el tamaño de lv_files. Para ello, utilizaremos el programa lvresize y luego resize2fs para adaptar el sistema de archivos según corresponda:

# df -h /srv/files/
Filesystem                        Size  Used Avail Use% Mounted on
/dev/mapper/vg_critical-lv_files  5.0G  4.6G  146M  97% /srv/files
# lvdisplay -C vg_critical/lv_files
  LV       VG          Attr     LSize Pool Origin Data%  Move Log Copy%  Convert
  lv_files vg_critical -wi-ao-- 5.00g
# vgdisplay -C vg_critical
  VG          #PV #LV #SN Attr   VSize VFree
  vg_critical   2   2   0 wz--n- 8.09g 2.09g
# lvresize -L 7G vg_critical/lv_files
  Extending logical volume lv_files to 7.00 GB
  Logical volume lv_files successfully resized
# lvdisplay -C vg_critical/lv_files
  LV       VG          Attr     LSize Pool Origin Data%  Move Log Copy%  Convert
  lv_files vg_critical -wi-ao-- 7.00g
# resize2fs /dev/vg_critical/lv_files
resize2fs 1.42.5 (29-Jul-2012)
Filesystem at /dev/vg_critical/lv_files is mounted on /srv/files; on-line resizing required
old_desc_blocks = 1, new_desc_blocks = 1
Performing an on-line resize of /dev/vg_critical/lv_files to 1835008 (4k) blocks.
The filesystem on /dev/vg_critical/lv_files is now 1835008 blocks long.

# df -h /srv/files/
Filesystem                        Size  Used Avail Use% Mounted on
/dev/mapper/vg_critical-lv_files  6.9G  4.6G  2.1G  70% /srv/files

PRECAUCIÓN Redimensión de sistemas de archivos

No todos los sistemas de archivos pueden cambiar su tamaño fácilmente; modificar un volúmen, por lo tanto, requerirá primero desmotar el sistema de archivos y volver a montarlo luego. Por supuesto, si uno desea disminuir el espacio asignado a un LV, primero debe reducir el sistema de archivos; el orden se invierte cuando el cambio de tamaño es en la otra dirección: primero debe aumentar el volumen lógico antes que el sistema de archivos que contiene. Es bastante directo ya que en ningún momento el sistema de archivos puede ser más grande que el dispositivo de bloques en el que reside (tanto cuando éste dispositivo sea una partición física o volumen lógico).

Los sistemas de archivos ext3, ext4 y xfs pueden agrandarse sin desmontarlos; deberá desmontarlos para reducirlos. El sistema de archivos reiserfs permite cambiar el tamaño en cualquier dirección sin desmontarlo. El venerable ext2 no lo permite y siempre necesitará desmontarlo primero.

Podemos proceder de una forma similar para extender el volumen que almacena la base de datos, sólo que habremos alcanzado el límite de espacio disponible del VG:

# df -h /srv/base/
Filesystem                       Size  Used Avail Use% Mounted on
/dev/mapper/vg_critical-lv_base 1008M  854M  104M  90% /srv/base
# vgdisplay -C vg_critical
  VG          #PV #LV #SN Attr   VSize VFree 
  vg_critical   2   2   0 wz--n- 8.09g 92.00m

Esto no importa ya que LVM permite agregar volúmenes físicos a grupos de volúmenes existentes. Por ejemplo, podríamos haber notado que la partición sdb1, que se encontraba fuera de LVM hasta ahora, sólo contenía archivos que podían ser movidos a lv_backups. Ahora podremos reciclarla e integrarla al grupo de volúmenes y reclamar así espacio disponible. Este es el propósito del programa vgextend. Por supuesto, debe prepara la partición como un volúmen físico antes. Una vez que extendió el VG, puede ejecutar órdenes similares a las anteriores para aumentar el volumen lógico y luego el sistema de archivos:

# pvcreate /dev/sdb1
  Writing physical volume data to disk "/dev/sdb1"
  Physical volume "/dev/sdb1" successfully created
# vgextend vg_critical /dev/sdb1
  Volume group "vg_critical" successfully extended
# vgdisplay -C vg_critical
  VG          #PV #LV #SN Attr   VSize VFree
  vg_critical   3   2   0 wz--n- 9.09g 1.09g
# [...]
[...]
# df -h /srv/base/
Filesystem                       Size  Used Avail Use% Mounted on
/dev/mapper/vg_critical-lv_base  2.0G  854M  1.1G  45% /srv/base

YENDO MÁS ALLÁ LVM avanzado

LVM también se adapta a usuarios más avanzados que pueden especificar a mano muchos detalles. Por ejemplo, un administrador puede adaptar el tamaño de los bloques que componen a los volúmenes lógicos y físicos así como también la distribución física. También es posible mover bloques entre PVs, por ejemplo para ajustar el rendimiento o, lo que es menos interesante, liberar un PV cuando uno necesite extraer el disco físico correspondiente del VG (ya sea para asociarlo a otro VG o para eliminarlo completamente de LVM). Las páginas de manual que describen estos programas generalmente son claras y detalladas. Un buen punto de partida es la página de manual lvm(8).

12.1.3. ¿RAID o LVM?

Tanto RAID como LVM proveen ventajas indiscutibles tan pronto como uno deja el caso simple de un equipo de escritorio con sólo un disco duro en el que los patrones de uso no cambian con el tiempo. Sin embargo, RAID y LVM toman direcciones diferentes, con objetivos distintos y es legítimo preguntarse cuál utilizar. La respuestas más apropiada, por supuesto, dependerá de los requerimientos actuales y previstos.

Hay unos pocos casos simples en los que no surge esta pregunta. Si los requisitos son proteger los datos contra fallos de hardware, obviamente entonces configurará RAID en un array de discos redundantes ya que LVM no soluciona este problema realmente. Si, por el otro lado, necesita un esquema de almacenamiento flexible en el que los volúmenes sean independientes de la distribución física de los discos, RAID no es de mucha ayuda y LVM es la elección natural.

NOTA Si el rendimiento importa…

Si la velocidad de entrada/salida es esencial, especialmente en cuanto a tiempos de acceso, utilizar LVM y/o RAID es una de las numerosas combinaciones que tendrán impacto en el rendimiento y esto influenciará las decisiones sobre cuál elegir. Sin embargo, estas diferencias de rendimiento son realmente mínimas y sólo podrán ser medidas en unos pocos casos de uso. Si importa el rendimiento, la mejor ganancia que puede obtener sería utilizar medios de almacenamiento no rotativos (discos de estado sólido o SSDs, «Solid State Drives»); su costo por megabyte es más alto que otros discos duros estándar y su capacidad generalmente es menor, pero proveen un rendimiento excelente para accesos aleatorios. Si el patrón de uso incluye muchas operaciones de entrada/salida distribuídas en todo el sistema de archivos, por ejemplos en bases de datos donde se ejecutan frecuentemente consultas complejas, la ventaja de ejecutarlas en un SSD sobrepasan grandemente cualquier ganancia de elegir LVM sobre RAID o su inversa. En estas situaciones debe realizar su selección según consideraciones diferentes a sólo la velocidad ya que puede controlar este aspecto más fácilmente utilizando SSDs.

El tercer caso notable de uso es uno en el que uno sólo desea agrupar dos discos en un solo volumen, ya sea por razones de rendimiento o para tener sólo un sistema de archivos más grande que cualquiera de los discos disponibles. Puede solucionar este caso tanto con RAID-0 (o inclusive RAID lineal) como con un volumen LVM. Cuando se encuentre con esta situación, y sin limitaciones adicionales (por ejemplo, ser consistente con el resto de los equipos si sólo utilizan RAID), generalmente elegirá utilizar LVM. La configuración inicial es ligeramente más compleja y es compensada por la flexibilidad adicional que provee LVM si cambian los requisitos o necesita agregar nuevos discos.

Luego por supuesto, está el caso de uso realmente interesante, en el que el sistema de almacenamiento debe ser resistente a fallos de hardware y también flexible en cuanto a la asignación de volúmenes. Ni RAID ni LVM pueden solucionar ambos requisitos por sí mismos; no importa, esta es la situación en la que utilizaremos ambos al mismo tiempo — o más bien, uno sobre el otro. El esquema más utilizado, casi un estándar desde que RAID y LVM son suficientemente maduros, es asegurar redundancia en los datos primero agrupando discos en una cantidad menor de arrays RAID grandes y luego utilizar estos arrays RAID como volúmenes físicos LVM; conseguirá las particiones lógicas para los sistemas de archivo a partir de estos LVs. El punto fuerte de esta configuración es que, cuando falla un disco, sólo necesitará reconstruir una pequeña cantidad de arrays RAID, de esa forma limitando el tiempo que utiliza el administrador en recuperarlo.

Veamos un caso concreto: el departamento de relaciones públicas en Falcot Corp necesita una estación de trabajo para edición de video, pero el presupuesto del mismo no permite invertir en hardware de gama alta desde el principio. Se decide entonces utilizar el presupuesto en hardware específico a la naturaleza gráfica del trabajo (pantalla y tarjeta de video) y utilizar hardware genérico para el almacenamiento. Sin embargo, como es públicamente conocido, el video digital tiene ciertas necesidades particulares para su almacenamiento: una gran cantidad de datos que guardar y es importante la tasa de rendimiento para leer y escribir estos datos es importante para el rendimiento general del sistema (más que el tiempo típico de acceso, por ejemplo). Necesita cumplir estos requisitos con hardware genérico, en este caso dos discos duros SATA de 300 Gb; también debe hacer que los datos de sistema, y algunos datos de usuarios, puedan resistir fallos en el hardware. Los videos editados deben estar seguros, pero los videos que todavía no fueron editados son menos críticos ya que todavía se encuentran en cinta.

Satisfacemos estas limitaciones combinando RAID-1 y LVM. Conectamos los discos a dos controladoras SATA diferentes para optimizar el acceso en paralelo y reducir el riesgo de fallos simultáneos, por lo que aparecerán como sda y sdc. Los particionamos de forma idéntica según el siguiente esquema:

# fdisk -l /dev/sda

Disk /dev/hda: 300.0 GB, 300090728448 bytes
255 heads, 63 sectors/track, 36483 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00039a9f

   Device Boot      Start      End      Blocks   Id  System
/dev/sda1   *           1      124      995998+  fd  Linux raid autodetect
/dev/sda2             125      248      996030   82  Linux swap / Solaris
/dev/sda3             249    36483   291057637+   5  Extended
/dev/sda5             249    12697    99996561   fd  Linux raid autodetect
/dev/sda6           12698    25146    99996561   fd  Linux raid autodetect
/dev/sda7           25147    36483    91064421   8e  Linux LVM

Agrupamos las primeras particiones de ambos discos (de alrededor de 1 GB) en un volúmen RAID-1, md0. Utilizamos el espejo directamente para almacenar el sistema de archivos raíz.
Utilizamos las particiones sda2 y sdc2 como particiones de intercambio que proveen un total de 2 GB de espacio de intercambio. Con 1 GB de RAM, la estación de trabajo tiene una cantidad adecuada de memoria disponible.
Agrupamos las particiones sda5 y sdc5, así como también sda6 y sdc6, en dos nuevos volúmenes RAID-1 de alrededor de 100 GB cada uno: md1 y md2. Inicializamos ambos espejos como volúmenes físicos para LVM y se los asigna al grupo de volúmenes vg_raid. Por lo tanto, este VG contiene aproximadamente 200 GB de espacio seguro.
Utilizamos las particiones restantes, sda7 y sdc7, directamente como volúmenes físicos y las asignamos a otro VG llamado vg_bulk que contiene, de esa forma, alrededor de 200 GB de espacio.

Una vez que crearomos los VGs, podemos particionalos de forma muy flexible. Uno debe recordar que se preservarán los LVs creados en vg_raid aún si falla uno de los discos, pero no será el caso de los LVs creados en vg_bulk; por el otro lado, este último será resevado en paralelo en ambos discos lo que permitirá velocidades de lectura y escritura mayores para archivos grandes.

Creamos entonces los LVs lv_usr, lv_var y lv_home en vg_raid para almacenar los sistemas de archivos correspondientes; utilizaremos otro LV grande, lv_movies, para almacenar las versiones finales de los videos luego de editarlos. Dividiremos el otro VG en un gran lv_rushes, para datos directamente obtenidos de las cámaras de video digital, y lv_tmp para archivos temporales. La ubicación del área de trabajo es una decisión menos directa: si bien necesitamos buen rendimiento en dicho volúmen, ¿se justifica perder trabajo si falla un disco durante una sesión de edición? Dependiendo de la respuesta a dicha pregunta, crearemos el LV correspondiente en un VG o el otro.

Ahora tenemos tanto redundancia para datos importantes como flexibilidad sobre la forma en la que se divide el espacio disponible entre las aplicaciones. En caso que se instale nuevo software (para editar pistas de audio por ejemplo), puede aumentar sin problemas el LV que almacena /usr/.

NOTA ¿Porqué tres volúmenes RAID-1?

Podríamos haber creado sólo un volumen RAID-1 a utilizar como volumen físico para vg_raid. ¿Por qué creamos tres entonces?

El razonamiento para la primera división (md0 y los demás) es por seguridad de los datos: los datos escritos a ambos elementos de un espejo RAID-1 son exactamente los mismos, por lo que es posible evitar la capa RAID y montar uno de los discos directamente. En caso de un error del núcleo, por ejemplo, o si se corrompen los metadatos LVM todavía es posible arrancar un sistema mínimo para acceder datos críticos como la distribución de discos en los volúmenes RAID y LVM; podremos luego reconstruir los metadatos y acceder a los archivos nuevamente, para poder devolver el sistema a su estado normal.

El razonamiento para la segunda división (md1 vs. md2) es menos estricto y está más relacionado con el reconocimiento que el futuro es incierto. Cuando se ensambló el equipo, no se conocían exactamente los requisitos; también puede evolucionar con el tiempo. En nuestro caso, no podemos saber por adelantado la necesidad de espacio de almacenamiento de cada tipo de videos. Si un video en particular necesita una gran cantidad de videos sin editar, y el VG dedicado para datos redundantes no tiene más de la mitad del espacio disponible, podemos reutilizar parte de su espacio innecesario. Podemos quitar uno de los volúmenes físicos, por ejemplo md2 de vg_raid y asignarlo a vg_bulk directamente (si la duración esperada de la operación es suficientemente corta como para que no nos preocupe la pérdida temporal de rendimiento), o deshacer la configuración RAID en md2 e integrar sus componentes sda6 y sdc6 en el VG (que crecerá 200 GB en lugar de 100 GB); luego podremos aumentar el volumen lógico lv_rushes según se necesite.