Administración de Sistemas Avanzada

Eduardo Grosclaude, Miriam Lechner

2016-08-08

[2020/12/02, 20:47:40- Material en preparación]

Resumen
En este escrito se presenta la descripción y material inicial de la asignatura Administración de
Sistemas Avanzada, para la carrera de Tecnicatura Universitaria en Administración de Sistemas y
Software Libre, de la Universidad Nacional del Comahue.
La materia es cuatrimestral en modalidad presencial (actualmente a distancia por situación de pan-
demia COVID-19)y las clases son de carácter teórico-práctico, desarrolladas en forma colaborativa. Está
preparada con los objetivos generales de capacitar al estudiante para implementar configuraciones
especiales de almacenamiento, aplicar programación avanzada a la automatización de tareas,
y diseñar e implementar estrategias de respaldo y de tolerancia a fallos para servicios críticos.

1
ÍNDICE ÍNDICE

Índice

I La asignatura 6
1. Objetivos 6
De la carrera . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
De la asignatura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2. Contenidos 6
Contenidos mínimos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Programa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3. Bibliografía inicial 7
Biblioteca Virtual del MinCyT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

II Configuraciones de Almacenamiento 8
1. Contenidos 8

2. Dispositivos y sistemas de archivos (filesystems) 8

Dispositivos lógicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Dispositivos de bucle (loop devices) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Sistemas de archivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3. RAID 12
Niveles RAID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Modos de operación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Construcción y uso de un array RAID-1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

4. Administración de LVM 14
Introducción a LVM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Componentes de LVM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Uso de LVM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Redimensionamiento de volúmenes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Redimensionamiento automático . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Indicación del nuevo tamaño . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Bytes y extents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Snapshots y backups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Dimensionamiento del snapshot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Creación de snapshots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Lectura y escritura del LVO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Lectura y escritura del snapshot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Creación de backups con snapshots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Uso preventivo de snapshots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Reversión de snapshots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Eliminación del snapshot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Ejemplos LVM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Temas de práctica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

5. SMART 23
Atributos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Diagnósticos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Paquete smartmontools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

2
ÍNDICE ÍNDICE

III Estrategias de Respaldo 26

1. Copias de respaldo 26
Establecimiento de una política de copias de respaldo . . . . . . . . . . . . . . . . . . . . . . 26

2. Sincronización de archivos 27
Herramienta rsync . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Especificación del origen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Modo backup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3. Replicación de datos 28
Replicación con rsync . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Modo dry-run . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Replicación de particiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Comando dd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Comando partimage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Comando netcat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

4. Temas de práctica 30

IV Alta Disponibilidad 32
1. Conceptos de Disponibilidad 32
Alta Disponibilidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Redundancia y disponibilidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Métricas económicas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

2. Clustering 35

3. DRBD 38
Forma de operación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Recursos DRBD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Configuración de DRBD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Ejemplos de configuración . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Parámetros de configuración . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Ejecución de DRBD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Inicializar el dispositivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Activar el recurso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Establecer roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Uso del dispositivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Creación de filesystems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Tuning del filesystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Montado de los recursos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Failover manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Monitoreo de DRBD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Restricciones importantes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Notas de instalación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Temas de práctica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

V Virtualización 46

3
ÍNDICE ÍNDICE

1. Virtualización 46
Concepto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Arquitectura y terminología . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Tipos de virtualización de plataforma . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

2. Aplicaciones 48

4
ÍNDICE ÍNDICE

5
 2 CONTENIDOS

Parte I
La asignatura
1. Objetivos
De la carrera
Según el documento fundamental de la Tecnicatura, el o la Técnico/a Superior en Administración
de Sistemas y Software Libre estará capacitado/a para:
 Desarrollar actividades de administración de infraestructura. Comprendiendo la administración de
sistemas, redes y los distintos componentes que forman la infraestructura de tecnología de una
institución, ya sea pública o privada.
 Aportar criterios básicos para la toma de decisiones relativas a la adopción de nuevas tecnologías
libres.
 Desempeñarse como soporte técnico, solucionando problemas afines por medio de la comunicación
con comunidades de Software Libre, empresas y desarrolladores de software.
 Realizar tareas de trabajo en modo colaborativo, intrínseco al uso de tecnologías libres.
 Comprender y adoptar el estado del arte local, nacional y regional en lo referente a implementación
de tecnologías libres. Tanto en los aspectos técnicos como legales.

De la asignatura
 Saber implementar configuraciones especiales de almacenamiento
 Saber aplicar programación avanzada a la automatización de tareas
 Saber diseñar e implementar estrategias de respaldo
 Conocer formas de implementar estrategias de tolerancia a fallos para servicios críticos

2. Contenidos
Contenidos mínimos
 Instalación sobre configuraciones de almacenamiento especiales.
 Scripting avanzado.
 Planificación de tareas.
 Virtualización.
 Alta Disponibilidad.

Programa
1. Configuraciones de almacenamiento
 Arquitectura de E/S, Dispositivos de E/S, Filesystems
 Diseños típicos de almacenamiento
 Software RAID, instalación y mantenimiento niveles 0, 1, 10, 5
 LVM, instalación y mantenimiento
2. Estrategias de respaldo
 Copiado y sincronización de archivos
 Estrategias y herramientas de backup, LVM snapshots
 Control de versiones

6
 3 BIBLIOGRAFÍA INICIAL

3. Alta Disponibilidad
 Clustering de LB, de HA, de HPC. Conceptos de HA.
 Peacemaker/Corosync, DRBD, Clustering de aplicaciones
4. Virtualización
 Formas de virtualización, herramientas.
 Creación, instalación, migración, eliminación de MV y container.
 Container y VM.
 Concepto de Cloud. IaaS, PaaS, SaaS, etc.
5. Scripting avanzado
 Accesibilidad. Interfaz gráfica.
 Captura de señales: trap.

3. Bibliografía inicial
 Kemp, Juliet. Linux System Administration Recipes: A Problem-Solution Approach. Apress, 2009.
 Lakshman, Sarath. Linux Shell Scripting Cookbook Solve Real-World Shell Scripting Problems
with over 110 Simple but Incredibly Effective Recipes. Birmingham, U.K.: Packt Pub., 2011.
 Parker, Steve. Shell Scripting Expert Recipes for Linux, Bash, and More. Hoboken, N.J.; Chichester:
Wiley; John Wiley, 2011.
 K. Kopper, The Linux Enterprise Cluster: build a highly available cluster with commodity hardware
and free software. San Francisco: No Starch Press, 2005.
 Andrew Beekhof, Pacemaker 1.1 Cluster from scratch. 2016.
 R. Pollei, Debian 7 System Administration Best Practices. Birmingham: Packt Publishing, 2013.
 T. A. Limoncelli, C. J. Hogan, and S. R. Chalup, The practice of system and network administra-
tion. Upper Saddle River, N.J: Addison-Wesley, 2008.
 Chen, Peter M., et al., RAID: High-performance, reliable secondary storage. ACM Computing
Surveys (CSUR), 1994.
 S. van Vugt, Pro Linux high availability clustering. 2014.

Biblioteca Virtual del MinCyT

Biblioteca Virtual del MinCyT: http://www.biblioteca.mincyt.gob.ar/libros.
Títulos accesibles desde la UNC:
 C. Wolf and E. M. Halter, Virtualization from the desktop to the enterprise. Berkeley, CA; New
York, NY: Apress; Distributed in U.S. by Springer-Verlag New York, 2005; http://rd.springer.
com/book/10.1007/978-1-4302-0027-7.
 K. Schmidt, High availability and disaster recovery concepts, design, implementation. Berlin; Sprin-
ger, 2006; http://rd.springer.com/book/10.1007/3-540-34582-5.

7
 2 DISPOSITIVOS Y SISTEMAS DE ARCHIVOS (FILESYSTEMS)

Parte II
Configuraciones de Almacenamiento
1. Contenidos
En esta sección se desarrollan contenidos relacionados a la gestión de almacenamiento masivo.
Incluyendo conceptos y tecnologías. Los temas comprendidos serán:
1. Arquitectura de E/S, Dispositivos de E/S (particionado), Filesystems (sistemas de archivos).
2. Software RAID (implementación Linux MD), instalación y mantenimiento, niveles 0, 1, 10, 5.
3. Manejadores de volúmenes lógicos (implementación de LVM), instalación y mantenimiento
4. Diseños típicos de almacenamiento

2. Dispositivos y sistemas de archivos (filesystems)

Dispositivos lógicos
Los dispositivos lógicos de bloques están asociados a algún medio de almacenamiento, real o vir-
tual. Ejemplos de dispositivos de bloques que encontramos con frecuencia son /dev/sda, /dev/sda1,
/dev/dvd, etc. Estos estarán asociados a algún medio, como puede ser un disco magnético, una memoria
de estado sólido o un archivo dentro de un sistema de archivos, por mencionar algunas posibilidades.
En general se encontrarán bajo el directorio /dev dentro de la FSH (Filesystem Hierarchy).
Los dispositivos lógicos presentan una interfaz que provee direccionamiento random o directo, es
decir, sus bloques están numerados y se puede acceder a cualquier bloque con independencia de cuál
haya sido accedido anteriormente (operación de seek). Pueden directamente contener un sistema de
archivos u ofrecer soporte a otros dispositivos virtuales, que los agrupan (como los dispositivos RAID)
o en general los utilizan (como los dispositivos snapshot de LVM). Los dispositivos de bloques más
usuales con los que nos encontramos son los discos y las particiones, pero es interesante conocer otros
dispositivos que están soportados por volúmenes lógicos, archivos, u otros, remotos, que se acceden por
medio de la red.
Desde el punto de vista del administrador/ora de sistemas, los archivos de dispositivo serán el medio
para interactuar y gestionar el espacio provisto por el medio virtual o físico que representan. Es así que,
por ejemplo, a través de una herramienta como fdisk, podemos dar una estructura al espacio en un disco
magnético a través de la creación de una tabla de particiones sobre el dispositivo lógico asociado, por
ejemplo: fdisk /dev/sda

8
Dispositivos de bucle (loop devices) 2 DISPOSITIVOS Y SISTEMAS DE ARCHIVOS (FILESYSTEMS)

Figura 1: Esquema IO y dispositivos

Dispositivos de bucle (loop devices)

Los dispositivos de bucle (/dev/loop*) de los sistemas GNU/Linux nos permiten asociar un archivo
de dispositivo (bajo el directorio /dev) con un archivo regular dentro de un sistema de archivos. Esta
funcionalidad nos permite, por ejemplo, montar un sistema de archivos que se encuentre contenido
dentro del archivo regular (como puede ser una imagen ISO), o realizar pruebas simulando la presencia
de múltiples dispositivos.
Dentro de esta asignatura se desarrollarán tecnologías que permiten la combinación de distintos
medios de almacenamiento, con diferentes fines, por lo que utilizaremos los dispositivos de bucle para
simular una infraestructura con múltiples discos físicos.
La siguiente secuencia muestra la forma en que utilizaremos los dispositivos de bucle con un ejemplo.

Creando archivos regulares:

$ dd if=/dev/zero of=imagen.img bs=1024 count=1024
1024+0 records in
1024+0 records out
1048576 bytes (1.0 MB) copied, 0.00223564 s, 469 MB/s
$ ls -l imagen.img
-rw-r--r-- 1 root root 1048576 Sep 1 11:54 imagen.img

Asociando dispositivos loop a archivos regulares:

$ losetup /dev/loop0 imagen.img
$ losetup -a

9
Dispositivos de bucle (loop devices) 2 DISPOSITIVOS Y SISTEMAS DE ARCHIVOS (FILESYSTEMS)

/dev/loop0: [0808]:2260385 (/tmp/imagen.img)

Creando sistema de archivos en el dispositivo asociado:

$ mkfs -t ext3 /dev/loop0
mke2fs 1.42.8 (20-Jun-2013)

Filesystem too small for a journal

Discarding device blocks: done
Filesystem label=
OS type: Linux
Block size=1024 (log=0)
Fragment size=1024 (log=0)
Stride=0 blocks, Stripe width=0 blocks
128 inodes, 1024 blocks
51 blocks (4.98 %) reserved for the super user
First data block=1
Maximum filesystem blocks=1048576
1 block group
8192 blocks per group, 8192 fragments per group
128 inodes per group

Allocating group tables: 0/1 done

Writing inode tables: 0/1 done
Writing superblocks and filesystem accounting information: 0/1 done

Montando el sistema de archivos para su uso:

$ mkdir mnt
$ mount -o loop /dev/loop0 mnt
$ df -h mnt
Filesystem Size Used Avail Use % Mounted on
/dev/loop0 1003K 17K 915K 2 % /tmp/mnt
$ ls -l mnt
total 12
drwx------ 2 root root 12288 Sep 1 11:54 lost+found

Utilizando el sistema de archivos:

$ ls / > mnt/lista.txt
$ ls -l mnt
total 13
-rw-r--r-- 1 root root 167 Sep 1 11:54 lista.txt
drwx------ 2 root root 12288 Sep 1 11:54 lost+found
$ df -h mnt
Filesystem Size Used Avail Use % Mounted on
/dev/loop0 1003K 18K 914K 2 % /tmp/mnt

Redimension del archivo regular de base, aumento:

$ dd if=/dev/zero of=imagen.img bs=1024 count=1024 oflag=append conv=notrunc
1024+0 records in
1024+0 records out
1048576 bytes (1.0 MB) copied, 0.00206669 s, 507 MB/s
$ ls -l imagen.img
-rw-r--r-- 1 root root 2097152 Sep 1 11:54 imagen.img

Indicando al mecanismo de bucle el cambio en el archivo regular:

$ losetup -c /dev/loop0

10
Sistemas de archivos 2 DISPOSITIVOS Y SISTEMAS DE ARCHIVOS (FILESYSTEMS)

$ losetup -a
/dev/loop0: [0808]:2260385 (/tmp/imagen.img)
/dev/loop1: [0005]:5178 (/dev/loop0)

Redimension del sistema de archivos contenido en el dispositivo:

$ umount mnt
$ e2fsck -fp /dev/loop0
/dev/loop0: 12/128 files (0.0 % non-contiguous), 39/1024 blocks
$ resize2fs /dev/loop0
resize2fs 1.42.8 (20-Jun-2013)
Resizing the filesystem on /dev/loop0 to 2048 (1k) blocks.
The filesystem on /dev/loop0 is now 2048 blocks long.

Puesta en funcionamiento del cambio:

$ mount /dev/loop0 mnt
$ df -h mnt/
Filesystem Size Used Avail Use % Mounted on
/dev/loop0 2.0M 18K 1.9M 1 % /tmp/mnt

Sistemas de archivos
Los sistemas de archivos son piezas de software fundamentales del sistema operativo que permiten
el uso de los dispositivos de almacenamiento por parte de los usuarios del sistema. Sin sistemas de
archivos la organización del espacio de almacenamiento sería una tarea ardua. El sistema de archivos
será entonces el software que permite la gestión del espacio disponible en un dispositivo, a través de
la creación de estructuras lógicas (metadatos) dentro del espacio de almacenamiento, que permiten la
gestión del mismo. Estas estructuras son las que se crean dentro del espacio de almacenamiento al
utilizar comandos como mkfs. Los metadatos ocupan un espacio en sí mismos, es por esto que, al crear
el sistema de archivos, el tamaño utilizable resultante es menor al espacio real disponible. La elección
del tipo de sistema de archivos también impactará en este sentido, habrá sistemas de archivos con
metadatos más complejos y otros con metadatos más simples.
Existen múltiples sistemas de archivos, con características diversas y finalidades distintas. Todos ellos
tienen como fin gestionar el espacio. Encontramos sistemas simples, como FAT, hasta extremadamente
complejos como puede ser btrfs.
La elección de un sistema de archivos particular depende del uso y las características del almace-
namiento subyacente, así como del soporte provisto por el sistema operativo. Elegiremos sistemas de
archivos distintos para un pendrive, que para un disco magnético. Evaluaremos si se alojarán archi-
vos grandes o pequeños, etc. A continuación presentamos un conjunto de preguntas que deberíamos
responder al momento de elegir el software más adecuado:
 ¿Sobre qué medio físico voy a crear dicho sistema?
 ¿Cuál es el tamaño del sistemas de archivos?
 ¿Cuál es el tamaño esperable de los archivos a almacenar?
 ¿Es esperable que el sistema de archivos crezca?
 ¿Tasa anual de crecimiento?
 ¿Performance del sistema de archivos a largo plazo? (fragmentación).
 ¿Cuál es el estado de desarrollo del software en el sistema operativo destino?
 ¿Puedo migrar de un sistema de archivos a otro?
 El sistema de archivos considerado ¿está soportado en el sistema operativo destino?

11
 3 RAID

3. RAID
Los arrays RAID (Redundant Array of Independent Disks) son dispositivos virtuales creados co-
mo combinación de dos o más dispositivos físicos. El dispositivo virtual resultante puede contener un
filesystem.
Los diferentes modos de combinación de dispositivos, llamados niveles RAID, ofrecen diferentes
características de redundancia y performance. Un array RAID con redundancia ofrece protección contra
fallos de dispositivos.
Los dispositivos Software RAID de Linux son creados y manejados por el driver md (Multiple Device)
y por eso suelen recibir nombres como md0, md1, etc.
 Redundancia para tolerancia a fallos
 Mejoramiento de velocidad de acceso
 Hardware RAID, Fake RAID, Software RAID
 Niveles RAID
 RAID Devices
 Spare disks, faulty disks

Niveles RAID
Linear mode Dos o más dispositivos concatenados. La escritura de datos ocupa los dispositivos en el
orden en que son declarados. Sin redundancia. Mejora la performance cuando diferentes usuarios
acceden a diferentes secciones del file system, soportadas en diferentes dispositivos.
RAID-0 Las operaciones son distribuidas (striped) entre los dispositivos, alternando circularmente entre
ellos. Cada dispositivo se accede en paralelo, mejorando el rendimiento. Sin redundancia.
RAID-1 Dos o más dispositivos replicados (mirrored), con cero o más spares. Con redundancia. Los
dispositivos deben ser del mismo tamaño. Si existen spares, en caso de falla o salida de servicio
de un dispositivo, el sistema reconstruirá automáticamente una réplica de los datos sobre uno de
ellos. En un RAID-1 de N dispositivos, pueden fallar o quitarse hasta N − 1 de ellos sin afectar
la disponibilidad de los datos. Si N es grande, el bus de I/O puede ser un cuello de botella (al
contrario que en Hardware RAID-1). El scheduler de Software RAID en Linux asigna las lecturas
a aquel dispositivo cuya cabeza lectora está más cerca de la posición buscada.
RAID-4 No se usa frecuentemente. Usado sobre tres o más dispositivos. Mantiene información de
paridad sobre un dispositivo, y escribe sobre los restantes en la misma forma que RAID-0. El
tamaño del array será (N − 1) ∗ S, donde S es el tamaño del dispositivo de menor capacidad en el
array. Al fallar un dispositivo, los datos se reconstruirán automáticamente usando la información
de paridad. El dispositivo que soporta la paridad se constituye en el cuello de botella del sistema.
RAID-5 Utilizado sobre tres o más dispositivos con cero o más spares. El tamaño del dispositivo
RAID será (N − 1) ∗ S. La diferencia con RAID-4 es que la información de paridad se distribuye
entre los dispositivos, eliminando el cuello de botella de RAID-4 y obteniendo mejor performance
en lectura. Al fallar uno de los dispositivos, los datos siguen disponibles. Si existen spares, el
sistema reconstruirá automáticamente el dispositivo faltante. Si se pierden dos o más dispositivos
simultáneamente, o durante una reconstrucción, los datos se pierden definitivamente. RAID-5
sobrevive a la falla de un dispositivo, pero no de dos o más. La performance en lectura y escritura
mejora con respecto a un solo dispositivo.
RAID-6 Usado sobre cuatro o más dispositivos con cero o más spares. La diferencia con RAID-5 es
que existen dos diferentes bloques de información de paridad, distribuidos entre los dispositivos
participantes, mejorando la robustez. El tamaño del dispositivo RAID-6 es (N − 2) ∗ S. Si fallan
uno o dos de los dispositivos, los datos siguen disponibles. Si existen spares, el sistema reconstruirá
automáticamente los dispositivos faltante. La performance en lectura es similar a RAID-5, pero la
de escritura no es tan buena.

12
Modos de operación 3 RAID

RAID-10 Combinación de RAID-1 y RAID-0 completamente ejecutada por el kernel, más eficiente que
aplicar dos niveles de RAID independientemente. Es capaz de aumentar la eficiencia en lectura
de acuerdo a la cantidad de dispositivos, en lugar de la cantidad de pares RAID-1, ofreciendo un
95 % del rendimiento de RAID-0 con la misma cantidad de dispositivos. Los spares pueden ser
compartidos entre todos los pares RAID-1.

Modos de operación
Create Creación de un array nuevo con superblocks por cada dispositivo.
Assemble Ensamblar dispositivos componentes previamente creados para conformar un dispositivo
RAID activo. Los componentes pueden especificarse en el comando o ser identificados por scanning.
Follow o Monitor Monitorizar un dispositivo RAID y actuar en caso de eventos interesantes. No se
aplica a RAID niveles 0 ni linear, ya que sus componentes no poseen estados (failed, spare, missing).
Build Construir un array sin superblocks por dispositivo (para expertos).
Grow Extender o reducir un array, cambiando el tamaño de los componentes activos (RAID 1, 4, 5 y
6) o cambiando el número de dispositivos activos en RAID1.
Manage Manipular componentes específicos de un array, como al agregar nuevos dispositivos spare o
al eliminar dispositivos faulty.
Misc Toda otra clase de operaciones sobre arrays activos o sus componentes.

Construcción y uso de un array RAID-1

Crear particiones en ambos discos, tipo fd (Linux RAID autodetect)

fdisk /dev/sdb; fdisk /dev/sdc

Crear el array

mdadm --create /dev/md0 --level=1 --raid-devices=2 /dev/sdb1 /dev/sdc1

watch cat /proc/mdstat

Usar el array

mkfs -t ext3 /dev/md0

mkdir /datos
mount -t ext3 /dev/md0 /datos
cp /etc/hosts /datos
ll /datos

Examinar el array

cat /proc/mdstat
cat /proc/partitions
mdadm --examine --brief --scan --config=partitions
mdadm --examine /dev/sdc
mdadm --query --detail /dev/md0

La opción detail actúa sobre arrays, mientras que la opción examine se refiere a los dispositivos
subyacentes.
Crear script de alerta

cat > /root/raidalert

#!/bin/bash
echo $(date) $* >> /root/alert

13
 4 ADMINISTRACIÓN DE LVM

^D
chmod a+x /root/raidalert

Monitorear el arreglo con script de alerta

mdadm --monitor -1 --scan --config=partitions --program=/root/raidalert

Crear configuración

cat > /etc/mdadm.conf

DEVICE=/dev/sdb1 /dev/sdc1
ARRAY=/dev/md0 devices=/dev/sdb1,/dev/sdc1
PROGRAM=/root/raidalert

Establecer tarea periódica de monitoreo

crontab -e
MAILTO=""
*/2 * * * * /sbin/mdadm --monitor -1 --scan

Declarar un fallo

mdadm /dev/md0 -f /dev/sdb1

cat /root/alert

Quitar un disco del array

mdadm /dev/md0 -r /dev/sdb1

cat /root/alert

Reincorporar el disco al array

mdadm /dev/md0 -a /dev/sdb1

cat /proc/mdstat
cat /root/alert

Desactivar el array

mdadm --stop /dev/md0

En este último paso se detiene el array, sin embargo la información aún persiste en los dispositivos
lo que posibilita la re-construcción del mismo en caso de ser necesario (modo assemble). Para eliminar
la información referente al array, almacenada en cada componente del mismo, se proveen herramientas
específicas: ver zero-superblock en el manual en línea.

4. Administración de LVM
Introducción a LVM
El soporte habitual para los file systems de servidores son los discos magnéticos, particionados según
un cierto diseño definido al momento de la instalación del sistema. Las particiones se definen a nivel del
hardware. El conjunto de aplicaciones y servicios del sistema utiliza los filesystems que se instalan sobre
estas particiones.
Las particiones de disco son un concepto de hardware, y dado que las unidades de almacenamiento
se definen estáticamente al momento del particionamiento, presentan un problema de administración a
la hora de modificar sus tamaños.

14
Componentes de LVM 4 ADMINISTRACIÓN DE LVM

El diseño del particionamiento se prepara para distribuir adecuadamente el espacio de almacenamien-

to entre los diferentes destinos a los que se dedicará el sistema. Sin embargo, es frecuente que el patrón
de uso del sistema vaya cambiando, y el almacenamiento se vuelva insuficiente o quede distribuido en
forma inadecuada. La solución a este problema implica normalmente el re-particionamiento de los dis-
cos, operación que obliga a desmontar los filesystems y a interrumpir el servicio. Para redimensionar una
partición, normalmente es necesario el reinicio del equipo, con la consiguiente interrupción del servicio
en producción (es especial si hablamos de particiones en uso por parte del sistema).
La alternativa consiste en interponer una capa intermedia de software entre el hardware crudo,
con sus particiones, y los filesystems sobre los que descansan los servicios. Esta capa intermedia está
implementada por Logical Volume Manager (LVM). LVM es un subsistema orientado a flexibilizar la
administración de almacenamiento, al interponer una capa de software que implementa dispositivos de
bloques lógicos por encima de las particiones físicas.
Usando LVM, el almacenamiento queda estructurado en capas, y las unidades lógicas pueden crearse,
redimensionarse, o destruirse, sin necesidad de reinicio, desmontar ni detener el funcionamiento del
sistema. Con LVM pueden definirse por software contenedores de filesystems, de límites flexibles, que
admiten el redimensionamiento “en caliente”, es decir sin salir de actividad, mejorando la disponibilidad
general de los servicios.
Con LVM pueden agregarse unidades físicas mientras el hardware lo permita, extendiéndose dinámi-
camente las unidades lógicas y redistribuyendo el espacio disponible a conveniencia. Presenta también
otras ventajas como la posibilidad de extraer snapshots o instantáneas de un filesystem en funciona-
miento (para obtener backups consistentes a nivel de filesystem), y manipular con precisión el mapeo a
unidades físicas para aprovechar características del sistema (como striping sobre diferentes discos).

Componentes de LVM
En la terminología LVM, los dispositivos de bloques entregados al sistema LVM se llaman PV (physical
volumes). Cualquier dispositivo de bloques escribible puede convertirse en un PV de LVM. Esto incluye
particiones de discos y dispositivos múltiples como conjuntos RAID. Los PVs se agrupan en VGs (volume
groups) que funcionan como pools de almacenamiento físico. De cada pool pueden extraerse a discreción
LVs (logical volumes), que se comportan nuevamente como dispositivos de bloques, y que pueden, por
ejemplo, alojar filesystems. Estos serán los usuarios finales de la jerarquía (Fig. 2).
Conviene tener en mente la jerarquía de los siguientes elementos:
Volumen físico o PV (physical volume) Es un contenedor físico que ha sido agregado al
sistema LVM. Puede ser una partición u otro dispositivo de bloques adecuado.
Grupo de volúmenes o VG (volume group) Es un pool o repositorio de espacio confor-
mado por uno o varios PVs. Un VG ofrece un espacio de almacenamiento virtualmente
continuo, cuyo tamaño corresponde aproximadamente a la suma de los PVs que lo
constituyen. Los límites entre los PVs que conforman un VG son transparentes.
Volumen lógico o LV (logical volume) Es una zona de un VG que ha sido delimitada para
ser usada por otro software, como por ejemplo un filesystem. Los tamaños de los LVs
dentro de un VG no necesariamente coinciden con los de los PVs que los soportan.

Uso de LVM
Los pasos lógicos para utilizar almacenamiento bajo LVM son:
 Crear uno o más PVs a partir de particiones u otros dispositivos.
 Reunir los PVs en un VG con lo cual sus límites virtualmente desaparecen.
 Particionar lógicamente el VG en uno o más LVs y utilizarlos como normalmente se usan las
particiones.
El sistema LVM incluye comandos para realizar estas tareas y en general administrar todas estas
unidades. Con ellos se puede, dinámicamente:

15
Redimensionamiento de volúmenes 4 ADMINISTRACIÓN DE LVM

Figura 2: Jerarquía de componentes LVM

 Redimensionar LVs de modo de ocupar más o menos espacio dentro del VG.
 Aumentar la capacidad de los VGs con nuevos PVs sin detener el sistema.
 Mover LVs a nuevos PVs, más rápidos, sin detener el sistema.
 Usar striping entre PVs de un mismo VG para mejorar las prestaciones.
 Tomar una instantánea o snapshot de un LV para hacer un backup del filesystem contenido en el
LV.
 Tomar una instantánea como medida preventiva antes de una actualización o modificación.
Los comandos tienen nombres con los prefijos pv, vg, lv, etc. Además, el comando lvm ofrece una
consola donde se pueden dar esos comandos y pedir ayuda.

Redimensionamiento de volúmenes
Una vez creado un LV, su capacidad puede ser reducida o aumentada (siempre que exista espacio
extra en el VG que lo contiene) con los comandos lvreduce o lvresize. Si el LV redimensionado
contuviera un filesystem, éste también debe ser redimensionado en forma acorde.
 Si un filesystem debe ser extendido, primero debe extenderse el LV que lo contiene.
 Si un filesystem va a ser reducido, luego debe reducirse el LV que lo contiene (en caso contrario,
el espacio extra se desperdicia).
 Si un LV va a ser reducido, primero debe reducirse el filesystem que contiene.
 Si un LV va a ser extendido, luego debe extenderse el fileystem que contiene (en caso contrario,
el espacio extra se desperdicia).
 Si un LV que va a ser reducido está ocupado en un cierto porcentaje, la reducción del LV sólo
puede llevarse a cabo en forma segura en dicho porcentaje.
Este redimensionamiento del filesystem puede ser hecho por el administrador con un comando sepa-
rado, o automáticamente en el momento de redimensionar el LV.

16
Snapshots y backups 4 ADMINISTRACIÓN DE LVM

Original Comando Final

lvresize -r -L 10G vg0/lv0 10GB
50 GB lvresize -r -L -10G vg0/lv0 40GB
lvreduce -r -L -10G vg0/lv0 40GB
lvresize -r -L +10G vg0/lv0 60GB

Cuadro 1: Tamaños con y sin signo

Original Comando Final

lvresize -r -l 1000 vg0/lv0 4 GB 1000 extents = 1000 * 4 MB = 4 GB
lvresize -r -l +1000 vg0/lv0 44 GB 40 GB + 4 GB = 44 GB
lvresize -r -l +100 %LV vg0/lv0 80 GB Se duplica el tamaño del LV
40 GB lvresize -r -l -10 %LV vg0/lv0 36 GB Se reduce el LV en un 10 %
lvresize -r -l +10 %VG vg0/lv0 50 GB Se agrega un 10 % del total del VG
lvresize -r -l +10 %FREE vg0/lv0 46 GB Se agrega un 10 % del espacio libre del VG
lvresize -r -l +10 %ORIGIN vg0/snap 14 GB Si el snapshot era de 10 GB (un 25 %
del LVO), lo extiende en un 10 % del LVO

Cuadro 2: Uso de extents

Redimensionamiento automático
La herramienta resize2fs, que modifica el tamaño de un filesystem, es capaz de extender los
filesystems sin necesidad de desmontar. Sin embargo, para reducir el tamaño de un filesystem, será
necesario desmontarlo.
Aún más conveniente que resize2fs es la opción -r de los comandos lvreduce y lvresize. Esta opción
tiene en cuenta el tamaño final del LV que se está redimensionando, y modifica el tamaño del filesystem
contenido adecuadamente, todo en la misma secuencia de operación.

Indicación del nuevo tamaño

La opción -L (o –size) indica el nuevo tamaño del LV en bytes, con sufijos M (mega), G (giga), T
(tera), etc.
En el comando lvresize, si el tamaño se indica con un prefijo de signo más o menos, significa
que el tamaño debe aumentar o disminuir en la cantidad que se indica a continuación. En cambio, si
el tamaño no lleva prefijo, significa que esa cantidad debe ser el tamaño final del LV. En el comando
lvreduce sólo tiene sentido el signo menos (ejemplos en Cuadro 1).

Bytes y extents
El nuevo tamaño para un LV puede darse en múltiplos del byte (MB, GB, TB...) o en extents (la
unidad mínima de asignación de bloques de LVM, por defecto 4 MB). La opción -L (o –size) indica el
tamaño deseado en bytes, y -l (o –extents) en extents.
Al usar extents, se puede opcionalmente indicar el tamaño deseado en términos relativos del tamaño
del VG, del LV, o del espacio libre dentro del VG. Por ejemplo, supongamos que:
 el volumen lógico vg0/lv0 mide 40 GB,
 el VG vg0 que lo contiene mide 100 GB,
 el espacio del VG vg0 no ocupado por el LV vg0/lv0 está libre.
Bajo estas condiciones, diferentes comandos lvresize tienen los efectos que se ven en el Cuadro 2.

Snapshots y backups
Un snapshot es un LV virtual, especialmente preparado, asociado a un LV original cuyo estado se
necesita “congelar” para cualquier propósito de mantenimiento. Una vez creado el snapshot, mediante

17
Snapshots y backups 4 ADMINISTRACIÓN DE LVM

un mecanismo de copy-on-write (o COW), LVM provee una instantánea o vista inmutable del filesystem
original, aunque éste se actualice. Una vez creado el LV virtual de snapshot, sus contenidos son estáticos
y permanentemente iguales al LV original. Puede ser montado y usado como un filesystem corriente. El
snapshot es temporario y una vez utilizado se descarta.
La motivación principal del mecanismo de snapshots es la extracción de copias de respaldo. Durante
la operación del sistema, las aplicaciones y el kernel leen y escriben sobre archivos, y por lo tanto el
filesystem pasa por una sucesión de estados. Una operación de backup que se desarrolle concurrentemente
con la actividad del filesystem no garantiza la consistencia de la imagen obtenida, ya que archivos
diferentes pueden ser copiados en diferentes momentos, bajo diferentes estados del filesystem. Como
consecuencia, la imagen grabada no necesariamente representa un estado concreto de la aplicación; y
esto puede dar lugar a problemas al momento de la recuperación del backup.
Hay muchos escenarios posibles de inconsistencia. Algunos ejemplos son:
 Una aplicación que mantiene un archivo temporario en disco con modificaciones automáticas y
periódicas (por ejemplo, vi).
 Aplicaciones que mantienen conjuntos de archivos fuertemente acoplados (bases de datos com-
puestas por tablas e índices en archivos separados).
 Una instalación de un paquete de software, que suele afectar muchos directorios del sistema.
Una solución consiste en “congelar” de alguna forma el estado del filesystem durante la operación de
copia (por ejemplo, desmontándolo). Con LVM, gracias al mecanismo de COW, esta instantánea puede
ser obtenida sin detener la operación del LV original, o sea sin afectar la disponibilidad del servicio. La
operación con el filesystem del LV origen (LVO) no se interrumpe, ni modifica en nada la conducta de
las aplicaciones que lo estén usando.

Dimensionamiento del snapshot

Para la creación de un snapshot de un LVO se necesita contar con espacio extra disponible (no
utilizado por ningún LV) dentro del mismo VG al cual pertenece el LVO. Este espacio extra no necesita
ser del mismo tamaño que el LVO. Normalmente es suficiente un 15 % a 20 % del tamaño del LV original.
Si el VG no tiene suficiente espacio, debe extenderse previamente.
No es fácil determinar con precisión el tamaño del snapshot, ya que debe ser suficiente para contener
todos los bloques modificados en el LVO durante el tiempo en que se use el snapshot; y este conjunto de
bloques puede ser variable, dependiendo del patrón de uso del LVO y del medio hacia el cual se pretende
hacer el backup (otro disco local, un servidor en la red local, un servidor en una red remota, una unidad
de cinta, tienen diferente ancho de banda y diferente demora de grabación).
En el Cuadro 2 hay un ejemplo de redimensionamiento del LV snapshot en función del tamaño del
LVO.

Creación de snapshots
Crear un snapshot es preparar un nuevo LV, virtual, con un filesystem virtualmente propio, que se
monta en un punto de montado diferente del original (Fig. 3).

Figura 3: Un LVO y su snapshot

A partir de este momento se pueden hacer operaciones de lectura y escritura en ambos filesystems
separadamente, con efectos distintos en cada caso.

18
Snapshots y backups 4 ADMINISTRACIÓN DE LVM

Lectura y escritura del LVO

Los snapshots son creados tomando un espacio de bloques de datos (la tabla de excepciones) dentro
del mismo VG del LVO. Mientras un bloque no sea modificado, las operaciones de lectura lo recuperarán
del LVO. Pero, cada vez que se modifique un bloque del LVO, la versión original, sin modificar, de dicho
bloque, será copiada en el snapshot (Fig. 4).

Figura 4: Escritura de un bloque del LVO

Lectura y escritura del snapshot

De esta manera, el snapshot muestra siempre los contenidos originales del LVO (Fig. 5), salvo que
se modifiquen por alguna operación de escritura en el snapshot.

Figura 5: Lectura de un bloque desde el snapshot

Los LVs pueden declararse R/O o R/W. En LVM2, los snapshots son R/W por defecto. Al escribir
sobre un filesystem de un LV snapshot R/W, se grabará el bloque modificado en el espacio privado del

19
Creación de backups con snapshots 4 ADMINISTRACIÓN DE LVM

snapshot sin afectar el LVO (Fig. 6). Al eliminar el snapshot, todas las modificaciones hechas sobre el
mismo desaparecen.

Figura 6: Escritura sobre el snapshot

Creación de backups con snapshots

1. Se crea un snapshot del LV de interés.
2. Se monta el snapshot en modo R/O sobre un punto de montado conocido.
3. Se copian los archivos del snapshot con la técnica de backup que se desee.
4. Se verifica la integridad del backup.
5. Si la verificación no fue satisfactoria, se repite el backup.
6. En caso satisfactorio, el snapshot se destruye con lvremove <ID del snapshot>.

Uso preventivo de snapshots

El mecanismo de snapshots ofrece la posibilidad de recuperar el estado original del LVO al efectuar
operaciones que pueden afectar críticamente la integridad u operatividad del sistema, tales como pruebas
de instalación, modificación de configuraciones, etc.
Como se ha visto, el conjunto de datos almacenados en un snapshot está formado por bloques que,
o bien provienen del LVO original, en su estado anterior a ser modificados (Fig. 4), o bien, son bloques
de archivos que fueron modificados mediante operaciones regulares de escritura sobre el filesystem
localizado en el snapshot y montado en modo R/W (Fig. 6).
En ambos casos, este conjunto de bloques alojados en el snapshot puede volver a ser aplicado sobre el
LVO (o revertido) con la opción --merge del comando lvconvert. Este comando restituye (roll-back)
al LVO todos sus bloques originales, que fueron grabados temporariamente en el espacio de excepciones
del snapshot, y luego destruye el snapshot.

Reversión de snapshots
Ahora bien, al ser revertido el snapshot sobre el LVO:
 Si no ha habido ninguna operación de escritura sobre el filesystem del snapshot, el LVO vuelve al
estado original al momento de ser tomado el snapshot.

20
Eliminación del snapshot 4 ADMINISTRACIÓN DE LVM

 Si, en cambio, existen archivos en el snapshot que han sido modificados, al revertir el snapshot el
LVO cambia, asumiendo las modificaciones que se hayan hecho en el snapshot.
El resultado, para el LVO, será completamente diferente en uno y otro caso. Ambas propiedades
pueden aprovecharse para recuperar el estado después de una modificación que no ha sido satisfactoria,
con una de las dos técnicas siguientes.
Técnica 1 Con esta técnica, las modificaciones se realizan sobre el filesystem del LVO y en caso necesario
se revierten usando el snapshot intacto.
1. Crear el snapshot del LVO, con espacio suficiente para registrar las modificaciones que se
piensa hacer.
2. Ejecutar las operaciones críticas (instalar, actualizar, modificar) sobre el LVO.
3. Verificar el resultado.
 Si el resultado fue satisfactorio, destruir el snapshot con lvremove <ID snapshot>.

 Si el resultado no fue satisfactorio, recuperar el estado original del LVO con el comando

lvconvert --merge <ID del snapshot>.

4. El snapshot ha sido eliminado.
Técnica 2 Con esta técnica se deja el LVO fuera de línea, intacto, y se trabaja sobre el snapshot
montado en modo R/W.
1. Crear el snapshot del LVO, con espacio suficiente para registrar las modificaciones que se
piensa hacer.
2. Desmontar el LVO y montar en su lugar el snapshot.
3. Ejecutar las operaciones críticas (instalar, actualizar, modificar) sobre el snapshot.
4. Verificar el resultado.
 Si fue satisfactorio, se vuelcan las modificaciones al LVO con lvconvert --merge <ID
del snapshot>.
 Si no fue satisfactorio, se elimina el snapshot.

5. Finalmente, en uno u otro caso, el snapshot ha sido eliminado, y se vuelve a montar el LVO
en su lugar.

Eliminación del snapshot

El snapshot debe ser destruido al finalizar el backup o terminar de usarlo, ya que, al obligar a copiar
cada bloque del LVO que se modifica, representa un costo en performance del sistema de I/O. Por lo
demás, el snapshot se define con una cierta capacidad, que al ser excedida hace inutilizable el snapshot
completo.

Ejemplos LVM
Creación de Physical Volumes (PV)

fdisk /dev/sdb
pvcreate /dev/sdb1 /dev/sdb2
pvdisplay

Creación de Volume Groups (VG)

vgcreate vg0 /dev/sdb1 /dev/sdb2

vgdisplay

Creación de Logical Volumes (LV)

21
Ejemplos LVM 4 ADMINISTRACIÓN DE LVM

lvcreate --size 512M vg0 -n lvol0

lvcreate -l 50 %VG vg0 -n lvol1
lvcreate -l 50 %FREE vg0 -n lvol2
lvdisplay vg0

Examinar LVM

pvs
vgs
lvs
pvscan
vgscan
lvscan

Uso de volúmenes

mkfs -t ext3 /dev/vg0/lvol0

mkdir volumen
mount /dev/vg0/lvol0 volumen
cp *.gz volumen
ls -l volumen

Extensión de un volumen

umount /dev/vg0/lvol0
lvextend --size +1G vg0/lvol0
mount /dev/vg0/lvol0 volumen
resize2fs /dev/vg0/lvol0

Agregar un disco al sistema

fdisk /dev/hdd
pvcreate /dev/hdd1
vgextend vg0 /dev/hdd1
lvextend --size +1G vg0/lvol0
ext2online /dev/vg0/lvol0

Snapshot de un volumen

lvcreate -s -n snap --size 100M vg0/lvol0

ls -l /dev/vg0
mkdir volumen-snap
mount /dev/vg0/snap volumen-snap
ls -l volumen-snap/
rm volumen/archivo1.tar.gz volumen/archivo2.tar.gz
ls -l volumen-snap/

Destruir un snapshot

lvremove vg0/snap

22
Temas de práctica 5 SMART

Temas de práctica
1. Crear una partición, convertirla en PV, crear un VG y definir un LV lv0 dentro del mismo dejando
un 25 % del espacio libre. Crear un filesystem sobre el LV, montarlo y utilizarlo para administrar
archivos.
2. Definir un nuevo LV lv1 en el mismo VG creado anteriormente, ocupando la totalidad del espacio
del VG.
3. Crear otra partición en el mismo u otro medio de almacenamiento, convertirla en PV y adjuntarla
al VG del ejercicio anterior. Examinar el resultado de las operaciones con los comandos de revisión
correspondientes.
4. Extender el LV lv1 para ocupar nuevamente la totalidad del espacio del VG extendido. Crear un
filesystem sobre el LV, montarlo y utilizarlo para administrar archivos.
5. Modificar los tamaños de ambos LVs, extendiendo uno y reduciendo el otro. Recordar que al
reducir un LV se debe primero reducir el filesystem alojado, y que para extender un filesystem se
debe primero extender el LV que lo aloja. Comprobar que los filesystems alojados siguen siendo
funcionales.
6. Supongamos que, al querer crear un snapshot de un LV, el administrador recibe un mensaje de
error diciendo que el VG no cuenta con espacio disponible. Sugiera un método para enfrentar este
problema usando LVM.
7. Dado un LV, poner en práctica las técnicas de creación de snapshot para a) obtener un backup, y
b) realizar modificaciones sobre el LV volviendo después al estado original.

5. SMART
La tecnología SMART (Self-Monitoring, Analysis and Reporting Technology) es un conjunto de
funciones útiles para verificar la confiabilidad de los discos y predecir sus fallos. Estas funciones se
incorporan en casi todos los discos rígidos electromecánicos ATA y SCSI actuales, así como en los de
estado sólido. Los discos dotados de SMART pueden ejecutar varias clases de tests sobre sí mismos, y
reportar sus resultados.
La interfaz SMART puede ser usada por el hardware o desde software adecuado. Normalmente el
firmware BIOS puede hacer uso de SMART ejecutando un chequeo de salud de los discos al inicio
del equipo y denunciando problemas potenciales o existentes. El paquete de software smartmontools
permite utilizar las funciones de SMART de los discos desde varios sistemas operativos.

Atributos
La tecnología SMART incorpora sensores de ciertas variables físicas, y contadores de una cantidad
de eventos relevantes, que describen la historia y el estado de los discos. El firmware SMART del disco
almacena estos datos, llamados atributos, en memoria no volátil situada en el mismo disco, y los actualiza
automáticamente. Cada disco, dependiendo del fabricante, del modelo y del nivel de la especificación
ATA al cual adhiere, mantiene un conjunto de estos atributos. Se numeran entre 1 y 253, y tienen
nombres específicos. Se dice que dos terceras partes de los fallos de los discos pueden ser predichos
observando los valores de determinados atributos. También puede determinarse si un disco ha llegado
al fin de su vida útil en base a estos valores.
Los atributos SMART tienen un “valor crudo” o raw y un “valor normalizado”. El valor crudo de
cada atributo tiene una interpretación dada en ciertas unidades. En el caso del atributo 12 (Fig. 7),
llamado power_cycle_count, por ejemplo, el valor crudo es simplemente un entero que representa
la cantidad de veces que el disco ha sido activado; para otros atributos, debe interpretarse como una
temperatura en grados Celsius (atributo 194, temperature_celsius), una cantidad de horas (atributo
9, power_on_hours), etc. Estos valores de interpretación natural corren, lógicamente, sobre diferentes
escalas. El “valor normalizado” de un atributo, por el contrario, está siempre entre 1 y 254, y se obtiene
del valor crudo mediante una función matemática que es computada por el firmware del mismo disco.
Estos valores normalizados, al ser comparados con determinados umbrales, denuncian la aparición de

23
Diagnósticos 5 SMART

problemas. El fabricante del disco, que es quien conoce los detalles de construcción y funcionamiento
del disco, provee el algoritmo para computar la función de normalización y el valor del umbral para
cada atributo. SMART almacena el valor normalizado actual y el “peor valor” histórico (el menor valor
normalizado obtenido desde la primera puesta en operación del disco hasta el momento actual) de cada
atributo.

Diagnósticos
SMART agrupa los atributos en dos clases: Old Age y Pre-failure. Los primeros sirven para diagnosti-
car cuándo un disco ha llegado al término de su vida útil, y los segundos para diagnosticar fallos efectivos
o inminentes de los discos. Si, en algún caso, el valor normalizado de un atributo resulta inferior o igual
a su umbral, entonces el diagnóstico depende del tipo del atributo. Si un disco tiene un atributo de tipo
Old Age cuyo valor normalizado es inferior al umbral, entonces se concluye que el disco ha superado su
vida útil según el diseño del producto. Si un atributo es de tipo Pre-failure y su valor normalizado es
inferior al umbral, entonces se anuncia un fallo inminente en 24 horas1 . Si el “peor valor” de un atributo
de tipo Pre-failure es menor que el umbral, es indicio seguro de que el disco ha presentado un fallo en
algún momento anterior.

Figura 7: Parte del informe SMART

Tests
SMART provee tres clases de tests, que pueden hacerse sin riesgo durante la operación normal del
sistema y no causan errores de lectura ni de escritura. La primera categoría se llama online testing, y no
tiene efecto sobre la performance del dispositivo. La segunda categoría se llama offline testing, y puede
causar una degradación de la performance, aunque en la práctica esto es raro porque el disco suspende
el test cada vez que hay actividad de lectura o escritura. Estas dos primeras categorías de tests deberían
más bien llamarse “adquisición de datos”, ya que simplemente se ocupan de actualizar constantemente
los valores de los atributos. La tercera categoría es un test propiamente dicho, y se llama self test.

1
En un estudio publicado por Google (Eduardo Pinheiro et al., Failure Trends in a Large Disk Drive Population. USENIX
V, 2007) se muestra evidencia, obtenida sobre una población muy grande, de que los fallos de discos están correlacionados
sobre todo con dos variables mantenidas por SMART: los errores de superficie (scan errors) y los eventos de reubicación de
sectores (reallocation count).

24
Paquete smartmontools 5 SMART

Paquete smartmontools
Comprende dos componentes: el daemon smartd y la interfaz de usuario smartctl. El daemon smartd
habilita las funciones de SMART en los discos y consulta su estado cada cierto intervalo. Los parámetros
de operación de smartd se indican en su archivo de configuración /etc/smartd.conf. La herramienta
smartctl sirve para consultar el estado de los discos y ejecutar tests.

25
 1 COPIAS DE RESPALDO

Parte III
Estrategias de Respaldo
1. Copias de respaldo
Establecimiento de una política de copias de respaldo
La estrategia de copias de respaldo (backup en inglés) implica mucho más que la decisión de qué
herramienta particular utilizar (tar, rsync, etc.) y dónde almacenar las copias. A continuación se enumeran
algunos de los aspectos principales que el administrador deberá contemplar a la hora de definir la política
de copias de respaldo de la organización.
 Propósitos y requerimientos legales, confidencialidad, etc.
 Archivos a respaldar
 Archivos de sistema, de los usuarios, de las aplicaciones
 Vuelcos de bases de datos, formatos portables.
 Dinámica de los archivos
 Estáticos o volátiles
 Tasa de crecimiento
 Período de cobertura (ventana de seguridad)
 Esquema y política de respaldo
 Quién es responsable
 Frecuencia y alcance de cada operación de backup
 Diarios, semanales
 Completos, diferenciales, incrementales
 Almacenamiento del respaldo
 Dónde se guarda
 Quién y cómo accede
 Recuperación de desastres, sitios remotos
 Medios de respaldo (cinta, disco, DVD...)
 Costo en tiempo de respaldo
 Costo en tiempo de restauración
 Costo monetario por byte de almacenamiento
 Disponibilidad tecnológica
 Presupuesto en medios
 Herramienta y formato (ftp, sftp, scp, tar, cpio, rsync, dd...)
 Sistema de apoyo (AMANDA, Bacula, BackupPC, Mondo...)
 Procedimiento de restauración
 Procedimiento de verificación
 Eliminación del respaldo
 Quién lo hace
 El medio se destruye o se reutiliza
 ¿Cómo escala la solución? ¿Se adapta al crecimiento de los datos?

26
 2 SINCRONIZACIÓN DE ARCHIVOS

2. Sincronización de archivos
Herramienta rsync
Rsync es un comando de sincronización de directorios y archivos. Puede usarse básicamente como
un reemplazo de los comandos rcp o scp, pero presenta gran cantidad de opciones interesantes. Entre
otras cosas, utiliza un algoritmo propio para computar las diferencias entre los archivos origen y destino
antes de iniciar la copia, y transfiere únicamente las modificaciones. Es decir, para aquellos archivos que
son diferentes entre origen y destino, únicamente copia aquellos bloques de datos que son efectivamente
diferentes2 .
Las opciones de rsync son muy numerosas (ver Anexo ??). Algunas de las más utilizadas:

rsync -av \ # modo archive y modo verbose

--compress \ # comprimir al transferir
--force \ # borrar directorios aun si no vacios
--delete \ # borrar archivos no existentes
--delete-excluded \ # borrar tambien los excluidos
--ignore-errors \ # borrar aun bajo error
--exclude-from=exclude_file \ # excluir los archivos listados
--backup \ # modo backup
--backup-dir=‘date + %Y- %m- %d‘ \ # directorio del modo backup
origen destino

La opción -a funciona como sinónimo de un conjunto de otras opciones convenientes para las copias
de respaldo en general. Esta opción equivale a -rlptgoD, que se traduce como r=recursivo; l=respetar los
links simbólicos; p=preservar los permisos, t=los tiempos de acceso de los archivos, g=el grupo y o=el
dueño; y D=recrear los pseudoarchivos de dispositivos en el lado destino. La compresión de archivos
será conveniente cuando origen y destino se sitúen en equipos diferentes sobre la red.
Rsync puede usarse de muchas formas (man rsync), algunas de ellas:
 Copia de archivos locales, cuando ninguno de los elementos origen y destino contiene un separador
dos puntos (“:”).
 Copia entre host local y host remoto usando un shell remoto (por defecto, ssh) como transporte,
cuando el destino contiene “:”.
 Copia desde un servidor rsync remoto al host local, cuando el origen contiene un separador “::” o
es un URL que comienza en “rsync://”
 Copia entre el host local y un servidor rsync en el host remoto usando un shell como transporte,
caso en que el origen contiene un separador “::” y se da la opción –rsh=COMMAND

Especificación del origen

La sintaxis de rsync tiene una particularidad: al especificar el directorio origen de la copia debe
tenerse en cuenta que una barra al final (“/”) indica copiar solamente los contenidos del directorio
origen, mientras que si no está presente la barra se entiende que el directorio también debe copiarse en
el destino.

$ ll xmms
total 2052
-rw-rw-r-- 1 oso oso 1973069 Aug 5 11:18 xmms-1.2.10-16.i386.rpm
-rw-rw-r-- 1 oso oso 36388 Aug 5 11:18 xmms-cdread-0.14-6.a.i386.rpm
-rw-rw-r-- 1 oso oso 79784 Aug 5 11:18 xmms-mp3-1.2.10-0.lvn.3.4.i386.rpm

El comando rsync -avz xmms/ xmms2 copiará los tres archivos en un nuevo directorio llamado
xmms2. En cambio, el comando rsync -avz xmms xmms2 producirá lo siguiente.

2
https://rsync.samba.org/tech_report/

27
 3 REPLICACIÓN DE DATOS

$ rsync -avz xmms xmms2

building file list ... done
created directory xmms2
xmms/
xmms/xmms-1.2.10-16.i386.rpm
xmms/xmms-cdread-0.14-6.a.i386.rpm
xmms/xmms-mp3-1.2.10-0.lvn.3.4.i386.rpm

sent 2068345 bytes received 92 bytes 827374.80 bytes/sec

total size is 2089241 speedup is 1.01
$ ll xmms2
total 4
drwxrwxr-x 2 oso oso 4096 Aug 5 11:28 xmms

Modo backup
El modo backup de rsync hace que los archivos preexistentes en el destino sean renombrados cada
vez que se reemplazan o se borran. La opción –backup-dir controla dónde serán creadas estas copias de
backup con nuevos nombres. La opción –suffix indica qué extensión tendrán estos archivos (por defecto
se agrega un signo “~”). En el caso anterior, supongamos que luego de hacer la copia, se modifican los
archivos presentes en xmms.

$ ll xmms2/xmms/
total 2052
-rw-rw-r-- 1 oso oso 1973069 Aug 5 11:18 xmms-1.2.10-16.i386.rpm
-rw-rw-r-- 1 oso oso 36388 Aug 5 11:18 xmms-cdread-0.14-6.a.i386.rpm
-rw-rw-r-- 1 oso oso 79784 Aug 5 11:18 xmms-mp3-1.2.10-0.lvn.3.4.i386.rpm
$ touch xmms/*
$ rsync -avz --backup xmms xmms2
building file list ... done
xmms/xmms-1.2.10-16.i386.rpm
xmms/xmms-cdread-0.14-6.a.i386.rpm
xmms/xmms-mp3-1.2.10-0.lvn.3.4.i386.rpm

sent 2068339 bytes received 86 bytes 827370.00 bytes/sec

total size is 2089241 speedup is 1.01
$ ll xmms2/xmms/
total 4104
-rw-rw-r-- 1 oso oso 1973069 Aug 5 11:30 xmms-1.2.10-16.i386.rpm
-rw-rw-r-- 1 oso oso 1973069 Aug 5 11:18 xmms-1.2.10-16.i386.rpm~
-rw-rw-r-- 1 oso oso 36388 Aug 5 11:30 xmms-cdread-0.14-6.a.i386.rpm
-rw-rw-r-- 1 oso oso 36388 Aug 5 11:18 xmms-cdread-0.14-6.a.i386.rpm~
-rw-rw-r-- 1 oso oso 79784 Aug 5 11:30 xmms-mp3-1.2.10-0.lvn.3.4.i386.rpm
-rw-rw-r-- 1 oso oso 79784 Aug 5 11:18 xmms-mp3-1.2.10-0.lvn.3.4.i386.rpm~

3. Replicación de datos
Más allá de las diferentes alternativas para realizar la copia periódica de archivos, con una u otra
herramienta, está el concepto de replicación de información. Su propósito es diferente del de la copia
de respaldo. En lugar de proteger los datos, manteniendo una historia de copias a través del tiempo,
la replicación busca aumentar la disponibilidad de los datos, manteniendo dos imágenes iguales en dos
lugares de almacenamiento.

28
Replicación con rsync 3 REPLICACIÓN DE DATOS

Esta forma de tratamiento de la información no protege de pérdidas o errores, pero facilita el rápido
regreso a la operación de un sistema ante fallas de hardware. La replicación puede ser:
 Asimétrica: una copia es la copia maestra y la segunda recibe las modificaciones, ó simétrica:
ambas copias reciben las modificaciones de la otra;
 Continua: disparada por eventos de filesystem, o administrativa: accionada por el administrador.
El regreso a la operación de un sistema con fallos puede ser un proceso manual, como en el caso de
clonar sobre bare metal (hardware desnudo) un sistema completo cuyo hardware ha quedado inutilizado,
o automático, como en los clusters de Alta Disponibilidad.
Herramientas que permiten ejecutar replicación, con diferentes alcances y objetivos, son los utilitarios
rsync, csync2, unison (que utilizan el algoritmo de rsync), los sistemas de control de versiones como
git o Subversion, filesystems distribuidos como Lustre o GlusterFS, los sistemas de almacenamiento en
nube con clientes automáticos, como Dropbox o Owncloud, la clonación de máquinas virtuales, y el
dispositivo de bloques replicado DRBD.

Replicación con rsync

El comando rsync siguiente tomará las acciones necesarias para obtener una réplica del directorio
/datos en el servidor backupserver, directorio /backups. La opción -a copiará todos los archivos en
todos los subdirectorios del directorio origen que no existan en el directorio destino, o que hayan sido
modificados, preservando los permisos; e ignorará todos aquellos archivos que sean iguales en ambos
directorios. Además, la opción –delete borrará los archivos en el directorio destino que no existan en el
origen.

rsync -aE --delete /datos backupserver.ejemplo.com.ar:/backups

Modo dry-run
Por supuesto, la opción –delete es peligrosa. Para verificar cuál será el efecto de un comando rsync
antes de ejecutarlo, se puede utilizar la opción -n o su sinónimo –dry-run.

Replicación de particiones
Una extensión de la idea de backup es la de crear imágenes de particiones completas de un sistema,
de modo de poder recuperarlo ante fallas generalizadas en menos tiempo y con menos trabajo que una
reinstalación. Esta técnica es conveniente para aquellas particiones que alojan filesystems “de sistema”3 ,
es decir, donde los datos son mayormente binarios o archivos de configuración de sistema, que no son
afectados por el trabajo cotidiano del usuario.

Comando dd
Una herramienta útil para el respaldo de particiones completas es el utilitario dd. Con él se puede
obtener una imagen de una partición o dispositivo completo.

dd if=/dev/sda1 of=part1.dd; scp part1.dd serverbackup.ejemplo.com.ar:

dd if=/dev/fd0 of=diskette.img

Un uso alternativo es el respaldo de las tablas de particiones (siempre y cuando estemos hablando
de particiones de tamaño y posición fija como MBR/msdos):

dd if=/dev/sda of=tpart.dd bs=1K count=1

3
Es conveniente probar la técnica al menos una vez para el sistema en cuestión, ya que en algunos sistemas modernos
podría no funcionar al reemplazar el hardware por uno diferente.

29
 4 TEMAS DE PRÁCTICA

Si se necesitara recuperar un conjunto de archivos de una imagen de una partición o dispositivo,

puede hacerse montando la imagen sobre un directorio vacío, como si fuera un dispositivo físico. La
opción de mount que permite esto es loop.

mount -t vfat -o ro,loop /backups/partwin.img /mnt/rescate

cp /mnt/rescate/* /datos

Comando partimage
La réplica de particiones con dd, sin embargo, carece de flexibilidad. Los backups son del mismo
tamaño que la partición, y son difíciles de manipular. Un utilitario tal como partimage tiene conocimiento
del filesystem, copia solamente los bloques en uso del dispositivo, y opcionalmente aplica compresión.
Además, puede dividir el respaldo en múltiples archivos para facilitar el almacenamiento. Puede ser
usado en volúmenes de los diferentes sistemas de archivos de Linux, tanto como en FAT o NTFS. Tiene
un modo interactivo y uno de línea de comandos.
Tanto partimage como dd tienen limitaciones. No se puede recuperar un backup sobre una partición
de tamaño menor que la original. En caso de ser sobre una de tamaño mayor, el espacio sobrante se
desaprovecha, salvo que se redimensione el filesystem con una herramienta tal como resize2fs. No es
sencillo recuperar selectivamente un conjunto de archivos de una imagen.

Comando netcat
El comando nc (o netcat) permite crear una conexión entre dos equipos a través de la red y utilizar
entrada y salida standard para transferir información. Esto puede aprovecharse para la replicación de
particiones de forma muy simple. El siguiente ejemplo utiliza el comando dd para crear un flujo de bytes
directamente de una partición del equipo origen, que se desea replicar.

# en el host origen
dd if=/dev/sda5 | nc 10.0.0.2 3000

# en el host destino
nc -l -p 3000 | dd of=/dev/sda3

El flujo de bytes es emitido por la salida standard del comando dd y entubado a la entrada del
comando nc que se conecta con un servidor nc en el host destino. En este host se recibe el flujo a
través de la conexión y se entuba a la entrada standard de dd, que lo vuelca en la partición destino.
El resultado es una transferencia raw de la partición, sin almacenamiento intermedio. En el ejemplo, el
host origen tiene la dirección IP 10.0.0.1, y el destino, 10.0.0.2. El servidor nc en el destino atiende por
el port 3000. La partición 5 del primer host se copia en la partición 3 del segundo, la que debe tener al
menos el tamaño de la primera.

4. Temas de práctica
1. Utilizando rsync, ejecute una transferencia a través de la red, de un archivo de tamaño considerable.
Anote el tiempo que registra el programa. Verifique las opciones de compresión que está utilizando
su comando.
2. Modifique el archivo anterior, realice nuevamente la transferencia. Anote el tiempo que registra el
programa. ¿Se transfirió el archivo en su totalidad?
3. Repita la experiencia utilizando scp. Verifique las opciones de compresión de modo que la compa-
ración sea justa. Puede usar el comando time para obtener el tiempo real de ejecución. Compare
los tiempos.
4. Repita una vez más la transferencia utilizando rsync, sin eliminar el archivo ya copiado en su lugar
de destino. Repita con scp y compare los tiempos.

30
 4 TEMAS DE PRÁCTICA

5. Prepare un directorio con uno o dos niveles de subdirectorios. Guarde archivos de tamaño conside-
rable en esa estructura. Repita el experimento anterior con rsync y con scp, registrando tiempos.
Luego modifique un único caracter de un único archivo de la jerarquía, repitiendo la transferencia
con ambas herramientas y registrando tiempos.
6. Clasifique en simétrica/asimétrica, continua/administrativa, la replicación ejecutada por herra-
mientas como rsync, csync2, unison, git, Subversion, Lustre, GlusterFS, Dropbox, Owncloud, la
clonación de máquinas virtuales, y el dispositivo de bloques replicado DRBD. ¿De qué forma ayuda
cada una a recuperar la operatividad de un equipo en caso de fallo?
7. Cuando rsync utiliza ssh como transporte, se adapta a la política de autenticación de usuarios
que utiliza ssh. ¿Cómo se puede evitar que rsync pida password de usuario para ejecutar una
transferencia entre diferentes hosts?
8. Prepare un script para replicar un directorio junto con sus subdirectorios, usando rsync, en otro
host. Instale el script en crontab. Verifique su funcionamiento modificando los contenidos del
directorio.
9. Modifique el script anterior para utilizar el modo backup de rsync en lugar de replicar el directorio.
10. ¿De qué forma, y en qué casos, puede ser de ayuda la herramienta anacron en lugar de cron?
11. Utilice el comando partimage para obtener una imagen de una partición de su sistema. Aplíquela
sobre otro disco. ¿Cómo se puede verificar que la replicación ha sido correcta?
12. ¿Tiene sentido el uso de la opción de compresión cuando trabajamos con rsync localmente?
13. Utilizando netcat y tar sin archivo intermedio transfiera un directorio y su contenido a un host
remoto.

31
 1 CONCEPTOS DE DISPONIBILIDAD

Parte IV
Alta Disponibilidad
1. Conceptos de Disponibilidad
Fallos
Un sistema falla cuando no cumple su especificación. Los fallos de un sistema pueden estar en un
fallo en algún componente. Los fallos de componentes pueden ser:
 Fallos transitorios: Rayos cósmicos que provocan algún desperfecto momentáneo en el procesador;
un mensaje de red no llega a destino pero sí lo hace al re-transmitir.
 Fallos intermitentes: mal contacto en un cable.
 Fallos permanentes: circuito quemado, error de software (bug).
Cualquiera de estos fallos puede ser clasificado como un fallo silencioso (también conocido como
fail-stop) ó un fallo bizantino. Un fallo silencioso es aquel en el que el componente fallido deja de
funcionar, sin producir resultados erróneos. Más precisamente, o bien no produce salida o, dicha salida
indica claramente que el componente ha fallado. Por otra parte, un fallo bizantino se da cuando el
componente falla sin detenerse pero produce resultados erróneos (el sistema cumple su función de forma
incorrecta). Este último tipo de fallos es claramente más complejo de identificar y solucionar.
La presencia de un fallo, ya sea en el hardware o en el software, deriva en un error interno en el
sistema. El error provee un cierto nivel de información acerca del fallo. Eventualmente, ese error puede
provocar una avería del sistema que es evidente a los usuarios del mismo. El objetivo será entonces,
evaluar posibles fallos, para evitar que los errores deriven en una avería.
Tolerancia a fallos: propiedad que permite a un sistema continuar operando correctamente ante
fallos de algunos de sus componentes. En este caso se asume que el sistema puede fallar y se diseña el
sistema para ello. Por ejemplo, el RAID 1 (espejado) es un ejemplo de un diseño tolerante a fallas para
el almacenamiento masivo.

Disponibilidad
A continuación se presentan una serie de expresiones matemáticas relativas al concepto de disponi-
bilidad.
 Cada sistema existe sobre un continuo de tiempo dividido en Tiempo entre Fallas (TTF) y Tiempo
de Reparación (TTR).
 MTBF (Mean Time Between Failures), tiempo promedio entre fallos.
 MTTR (Mean Time To Repair ), tiempo promedio para la reparación.
 La proporción del tiempo en la cual realmente está operando el sistema mide la disponibilidad.
 En promedio, D = M T BF/(M T BF + M T T R).
 La disponibilidad se elevará entonces aumentando el MTBF y/o reduciendo el MTTR.
 La selección de sistemas confiables a nivel de hardware apunta a aumentar el MTBF. Un
MTBF mayor implica un menor impacto de MTTR.
 La implementación de técnicas de Alta Disponibilidad pretende reducir lo más posible los
períodos de carencia de los servicios o TTR, por lo tanto el MTTR.
 En esta fórmula se consideran únicamente los tiempos de carencia del servicio no planificados.
Existen situaciones en las que es necesario planificar una parada de servicio. Por ejemplo, algunas
actualizaciones de sistemas, backups o cambios de configuración pueden requerir de una parada del
servicio. Estas paradas planificadas no son consideradas dentro de la medición anterior. En general
este tipo de paradas se acuerdan previamente con los usuarios del servicio para reducir el impacto. Se
establecen los caminos de acción y de recuperación en caso de ocurrir fallas no esperadas durante el

32
Alta Disponibilidad 1 CONCEPTOS DE DISPONIBILIDAD

procedimiento realizado, además de proveer una ventana de tiempo estimada en la que se restaura el
servicio.
Dentro de las paradas no planificadas podemos distinguir:
 Recuperables: situaciones en que la intervención de los administradores permite re-establecer el
servicio en un período de tiempo acotado. Por ejemplo: error de la aplicación, error del operador,
apagones, caídas de red, fallas de hardware.
 Desastres: de menor probabilidad pero de mayor impacto si no se toman medidas adicionales
a las convencionales. Por ejemplo: accidentes, robos, sabotajes, incendios, meteoros, catástrofes
naturales.
La no disponibilidad tiene generalmente un costo para la organización, y puede controlarse con medidas
especiales.

Alta Disponibilidad
Disponibilidad: cualidad de estar disponible.
Las técnicas de Alta Disponibilidad (High Availability, HA) buscan construir un sistema que dé sopor-
te para la provisión de un servicio durante la mayor parte del tiempo que sea posible. Las medidas para
lograr esta meta abarcan varios niveles de actividad, y van desde prácticas adecuadas de administración
de sistemas, pasando por elecciones especiales de soporte de hardware, políticas de backup, implantación
de sistemas especiales de HA con redundancia, hasta la preparación de estrategias de Recuperación de
Desastres (Disaster Recovery ). Las medidas se apoyan unas en otras, y deben ser implementadas en
orden creciente de complejidad y costo (Fig. 8).
Disponibilidad

Recuperación de desastres
Replicación
Failovers
Servicios y aplicaciones
Administración de clientes
Ambiente local
Inversión Redes
Discos y volúmenes
Backups confiables
Buenas prácticas de
administración de sistemas

Figura 8: Jerarquía de medidas de disponibilidad

Buenas prácticas de administración de sistemas: toma de decisiones correctas acerca del hard-
ware y software; consolidación de servidores; buenas políticas de seguridad; sistema de documentación;
sistema de control de cambios; cumplimiento de normas y estándares; elección correcta de personal;

33
Redundancia y disponibilidad 1 CONCEPTOS DE DISPONIBILIDAD

infraestructura documentada (cmdb); monitorización de la infraestructura; política de actualización y

mantenimiento, etc.
Discos y volúmenes: elección de hardware (discos, controladoras, SAN/NAS/DAS, HBAs, etc) ;
niveles de RAID; administración flexible del espacio (volúmenes); elección de los sistemas de archivos.
Ambiente local: todo lo relativo al lugar físico donde residen los equipos. Sistema de enfriamiento y
des-humidificación; ordenamiento del cableado (pisos técnicos); UPS, baterías; control de acceso físico;
limpieza ; rotulación e identificación, etc.
Administración de clientes: no esperar nada de los usuarios. Backup de equipos personales, no sólo
de servidores. Provisión e imagen lista para re-instalar. Capacitación. Centralizar directorios home, uso
a través de la red. Establecer áreas públicas de uso compartido (ej. uso de "la nube"). Uso de clientes
livianos (thin clients). Actualizaciones de software.
Alta disponibilidad no es:
 Servicio Continuo, donde el usuario no ve interrupciones del servicio.
 Tolerancia a Fallos, que es una cualidad de un determinado sistema para operar más allá de ciertos
fallos previstos.
 Balance de Carga, aunque algunos modelos de HA lo incluyen como beneficio adicional.
 Recuperación de Desastres, donde se supone que existe una pérdida de datos que se debe subsanar.
Al implementar medidas de Alta Disponibilidad no pretendemos servicio continuo. Sin embargo,
aunque el usuario puede llegar a percibir interrupciones o anomalías en el servicio, normalmente se
puede lograr un “tiempo de reparación” tolerable, y a veces imperceptible. En la práctica, ante un
evento de impacto, esto se traduce en una conexión interrumpida con el servicio pero que se recupera
dentro de las próximas acciones del cliente (siguientes reintentos de lectura por la aplicación, siguiente
click del usuario, etc.).

Redundancia y disponibilidad
El principio fundamental de HA es la eliminación de los puntos únicos de falla (Single Point of
Failure, SPOF ) por duplicación o multiplicación de puntos de servicio. Esta técnica se llama en general
redundancia.
Si un servicio tiene una disponibilidad de 90 % (o sea, una probabilidad de estar disponible igual a 0.9)
sobre un período dado, su probabilidad de carencia o no disponibilidad en ese período es 1 − 0,9 = 0,1.
Si el recurso puede implementarse en forma redundante, y suponiendo eventos de fallo independientes,
la probabilidad de que dos instancias del recurso estén no disponibles a la vez en ese mismo período es
0,1 ∗ 0,1 = 0,01; con lo cual la probabilidad de disponibilidad del servicio es ahora 1 − 0,01 = 0,99, o
sea 99 % para dicho período. Al agregarse la segunda instancia de recurso se ha eliminado el SPOF y
se ha ganado un orden de magnitud en disponibilidad.
Para ilustración, cuando un servicio tiene una disponibilidad del 99 % por año, esto quiere decir
que en promedio la no disponibilidad del servicio ocurrirá durante 3.65 días por año. En cambio, si la
disponibilidad es de 99.99 %, el servicio quedará no disponible a lo sumo durante 52.5 minutos por año.
La suposición de que los eventos de fallo son independientes se basa en que no existan SPOFs de
nivel superior, es decir, anteriores en la cadena de precondiciones para el servicio (por ejemplo, se supone
que existen diferentes líneas de alimentación eléctrica). No es posible construir un sistema completo sin
ningún SPOF, pero es posible delimitar ámbitos de responsabilidad donde no existan.

Métricas económicas
Probabilidad Cantidad de veces que se espera ocurra el evento durante la vida remanente del sistema.
Un evento que puede ocurrir semanalmente durante los próximos cinco años tiene una probabilidad
de 2604 .
Duración Cantidad de tiempo en que los usuarios carecerán del servicio a causa del evento. Incluye
el tiempo necesario para el restablecimiento del servicio y para notificar a los usuarios dicho
restablecimiento.
4
Este concepto de probabilidad se llama originalmente likelihood, y claramente no se trata del mismo concepto de la
probabilidad matemática, que únicamente puede tomar valores entre 0 y 1.

34
 2 CLUSTERING

Impacto Porcentaje de la comunidad de usuarios que se verá afectada por el evento.

 Cálculo de riesgos para cada evento ei en el sistema original
 Efecto Eb = P robabilidad ∗ Duración ∗ Impacto
P
 Riesgo Rb = Costo(N D) ∗ Eb (ei )
 Luego de implementar HA
 Efecto Ea = P robabilidadHA ∗ DuraciónHA ∗ ImpactoHA
P
 Riesgo Ra = Costo(N D) ∗ Ea (ei ) + Costo(HA)
 Ahorro A = Rb − Ra
 Retorno de inversión ROI = A/Costo(HA)

2. Clustering
Una arquitectura típica de Alta Disponibilidad es el cluster de HA (High Availability Cluster, HAC ),
donde dos o más nodos en una red ofrecen servicios en forma redundante. El HAC protege a los servicios
de los fallos del nodo que los soporta.
Este tipo de cluster no debe confundirse con los clusters de Computación de Altas Prestaciones (High
Performance Computing, HPC ) cuyo objetivo es lograr alta capacidad de procesamiento dividiendo la
ejecución de una tarea en varios procesadores, ni con los clusters de Balance de Carga, o Servidores
Virtuales, donde simultáneamente se brinda el mismo servicio pero distribuyéndolo sobre varios nodos.
Existen diferentes configuraciones, pero la más sencilla es la del cluster de dos nodos, donde uno es
el servidor activo o primario de un servicio, y el otro está normalmente en estado pasivo, secundario o
standby. La función del secundario, durante la operación normal, es la monitorización del primario para
detectar sus caídas o fallas y tomar el control de los servicios.
El proceso de migración de un servicio de un nodo a otro se llama failover. La acción de asumir el rol
de primario para un servicio desde la situación de standby se llama takeover. Cuando un sistema pierde
la característica de ser redundante, por fallo de todas las instancias menos una, se dice que trabaja en
modo degradado (momento en que se hace crítica la puesta en servicio de las demás instancias).
Los servicios protegidos por el HAC pueden ser varios de entre los normalmente brindados por un
nodo, como WWW, mail, LDAP, NFS, NIS, DHCP, SMB/CIFS, proxy/firewall, etc. y por supuesto el
almacenamiento compartido o replicado. En particular existe un recurso sujeto a failover que es una
dirección IP especial, de propiedad del cluster (Virtual IP, VIP). Es la dirección por donde se ofrecen
los servicios protegidos. Esta dirección migra convenientemente al nodo que detente el rol primario en
cada momento.
La decisión de si los servicios de un nodo, mientras su rol es secundario, están o no corriendo, y
en tal caso, en qué modo, es una cuestión de diseño del HAC. Dependiendo de la implementación del
servicio, puede ser suficiente el modo cold standby (los procesos servidores no están ejecutándose) o el
modo warm standby (los servidores están ejecutándose pero sin dar servicio). Este último modo tiene
una penalidad menor en tiempo de arranque de los servicios al momento del failover.
Un nodo puede ser a la vez primario para algunos servicios y secundario para otros, aunque en general
no aporta nada a la solución del problema de disponibilidad el hecho de distribuir los servicios (si los
equipos no son capaces de soportar la carga durante la caída del primario, no lograremos aumentar la
disponibilidad de todos modos). En cambio, tiene sentido la distribución de servicios cuando además se
pretende balance de carga, aunque entonces no se habla con propiedad de nodos en primario/standby,
ni de takeover.
En general, las aplicaciones responsables de ofrecer los servicios deben compartir alguna cantidad de
información de estado o de configuración, disponible a todos los nodos del cluster, para lo cual se agrega
un almacenamiento compartido o replicado. Si existe una sola instancia, compartida, de almacenamiento
(p. ej. mediante NFS, o mediante una única unidad de almacenamiento multihomed), se introducirá un
SPOF. La alternativa es la replicación del almacenamiento, que dependiendo de los objetivos del sistema
HA puede hacerse en varias formas y modos.
La replicación puede realizarse a nivel de bloques (donde se interpone un módulo de software especial
en el camino de I/O de los datos hacia el disco), de filesystem, o de archivos. Este último caso sería el

35
 2 CLUSTERING

de la replicación ejecutada por el administrador de sistemas a nivel de aplicación (con utilitarios como
rsync o similares). Para los clusters construidos sobre redes locales (i.e. sobre redes de baja latencia), es
conveniente ejecutar la replicación a nivel de bloques en modo sincrónico. Para clusters sobre WANs, o
para los procedimientos de recuperación de desastres, es preferible la replicación a nivel de aplicación.
 Formas de clustering
 de Alta Disponibilidad

 de Almacenamiento

 de Altas Prestaciones

 de Balance de Carga

 Alta Disponibilidad ->High Availability ->HA

 Recursos ->servicios
 Modelo de capas o niveles (clustering stack)
 Mensajería y pertenencia (messaging/membership agent): comunicaciones

 Gestión de recursos (cluster resource manager, CRM): lógica de asignación de recursos a

nodos
 Failover
 VIP (Virtual IP)

 Migración de recursos

 Almacenamiento compartido o replicado (Fig. 9)

◦ DAS (Direct Attached Storage)

◦ Unidades de disco locales

◦ Filesystem XFS, EXT4

◦ NAS (Network Attached Storage)

◦ Filesystem exportado por otro nodo, que se monta a través de la red

◦ NFS, SMB/CIFS

◦ SAN (Storage Area Network)

◦ Dispositivo de bloques que aparenta ser local pero es de almacenamiento externo,

exportado por otro nodo
◦ Tecnologías iSCSI, Fibre Channel

 Heartbeats, Quorum, Fencing, Split Brain, Amnesia, STONITH

◦ Los nodos de un cluster comprueban que pueden alcanzar a sus peers usando mensajes
cortos y periódicos llamados latidos (heartbeats).
◦ Si un nodo sufriera un fallo de red, dejaría de alcanzar a un peer y podría llegar errónea-

mente a la conclusión de que ha caído. Para separar este falso positivo de falla, los nodos
siguen protocolos distribuidos que comprueban que son capaces de alcanzar a otros, y
además algunos protocolos consultan a otros nodos si pueden alcanzar a los terceros,
sospechosos de fallo. Cuando existe una cantidad suficiente de nodos que están de acuer-
do sobre el estado de pertenencia de los demás miembros del cluster, se dice que existe
quorum, y sólo en ese caso se toman ciertas acciones.
◦ En un cluster de dos nodos, si éstos perdieran contacto entre sí pero no con el resto

de la red, ambos se considerarían a sí mismos únicos miembros vivos del cluster. Esta
condición se llama split brain o cerebro dividido. El cluster no es capaz de recuperarse
automáticamente de esta condición. Para evitarla, se aplica redundancia en las vías de
comunicación de heartbeats (normalmente, más de una interfaz de red, y a veces algún
canal secundario separado del subsistema de red, tal como una línea serial).
◦ En clusters de más de dos nodos, al perderse contacto con un nodo, el resto del cluster
cae en la incertidumbre sobre su estado. Cuando existe almacenamiento compartido, una
falla del nodo podría afectar a los servicios del cluster. Para evitarlo, el cluster utiliza
algún mecanismo de fencing (separar por la fuerza al nodo presuntamente fallado).
Por lo general estos mecanismos se basan en dispositivos que controlan físicamente la
alimentación de los nodos.

36
 2 CLUSTERING

◦ Cuando se pierde comunicación con un nodo por una cantidad de tiempo determinada, el
agente de comunicaciones, que vigila la pertenencia al cluster, debe accionar el dispositivo
de fencing y provocar una acción de STONITH (shoot the other node in the head),
apagándolo. Cuando no existe un dispositivo, sino que es el administrador del cluster
quien debe dar de baja manualmente al nodo fallado, se dice que el dispositivo es de tipo
meatware STONITH (,).
◦ En un cluster de dos o más nodos, puede suceder que caigan todos los nodos en un
determinado orden: digamos A, y luego B (asumiendo dos nodos). En esta situación,
el último estado consistente del cluster fue conocido por el nodo A (dicho estado se
encuentra en la configuración interna del nodo). Por lo que el nodo B, no estará al tanto
de ese último estado del cluster. Si el nodo B intentara unirse al cluster sin la presencia
del nodo A, este podría dañar al cluster debido a su desconocimiento de lo hecho por
A previo a su caída. Esta situación se conoce como Amnesia del nodo B, y debe ser
controlada por el cluster mediante algún mecanismo. En general, se prohibirá al nodo B
unirse al cluster hasta en tanto el nodo A retome la operación.
 Herramientas
 Heartbeat v.1, OpenAIS, Corosync, CMAN
 Heartbeat v.2.1.4+, Pacemaker, rgmanager
 LVS
 Configuraciones
 Activo/Pasivo
 Activo/Activo con balance de carga
 Activo/Pasivo con múltiples recursos

Figura 9: DAS, NAS, SAN

37
 3 DRBD

3. DRBD
DRBD (Distributed Replicated Block Device) es una tecnología implementada a nivel del kernel
Linux que efectúa una replicación automática, continua y asimétrica, de bloques de disco. El modo
de operación de DRBD es semejante a un conjunto RAID 1 donde ambos discos estuvieran en diferentes
hosts de la red (Fig. 10).

Aplicaciones Aplicaciones
Espacio
de
Bibliotecas Bibliotecas
usuario

System calls System calls

VFS VFS

EXT2 EXT3 GFS EXT2 EXT3 GFS

EXT4 VFAT EXT4 VFAT

NFS NFS
Kernel
XFS XFS
NTFS CIFS NTFS CIFS
iso9660 iso9660

LVM LVM

DRBD Primario DRBD Secundario

Hardware Dispositivos físicos Dispositivos físicos

Figura 10: Localización de DRBD en el stack de I/O

El driver DRBD está incorporado al kernel Linux desde la versión 2.6.33. Se ubica lógicamente entre
la cache de bloques del kernel y el almacenamiento físico, ofreciendo a los procesos usuarios la interfaz
de un dispositivo de bloques. El usuario normalmente utiliza este dispositivo para, por ejemplo, crear un
filesystem sobre él.
Para configurar un dispositivo DRBD debe dársele un soporte, es decir, un dispositivo de bloques
subyacente que le provea almacenamiento (tal como una partición o un volumen lógico), y un canal de
comunicación con su nodo peer.
En su configuración más habitual, DRBD impone roles primario y secundario a los nodos que in-
tervienen. En este modo, únicamente las aplicaciones corriendo en el nodo primario pueden utilizar el
espacio de almacenamiento ofrecido por el dispositivo DRBD. En particular, solamente el primario puede
montar ese dispositivo5 .

Forma de operación
 Toda actividad de lectura o escritura sobre el dispositivo soporte (creación de filesystem, escritura
de bloques de datos, borrado de archivos, etc.) pasa por el control del módulo DRBD.
5
En realidad, es posible una configuración de doble primario; pero para poder hacer accesos concurrentes en forma segura,
las aplicaciones que vayan a usar ese almacenamiento necesitan contar con un lock manager distribuido, que sólo está presente
en los filesystems de cluster como GFS2, GlusterFS u OCFS2.

38
Recursos DRBD 3 DRBD

 Cada modificación, antes de ser efectivizada en el nodo primario, es comunicada al módulo peer
secundario.
 Éste graba el bloque modificado en su soporte local y confirma la grabación.
 Recibida la confirmación, el nodo primario graba su copia del bloque en su propio soporte local.
Ante un evento de caída de uno u otro de los nodos, cuando se recupera el nodo perdido, ocurre
una resincronización automática. Cuando el nodo primario cae y se recupera, puede volver a ese rol o
no, dependiendo de una opción de configuración. El vínculo por el cual circulan los datos de bloques
que deben actualizarse en el secundario, y por donde se realizan las sincronizaciones, es una conexión
de red preferiblemente dedicada y diferente de la red de servicio, y de la mayor velocidad posible. Puede
funcionar tanto en LAN como en WAN, utilizando diferentes protocolos de replicación para favorecer la
performance en caso de alta latencia (como en WAN) o maximizar la expectativa de consistencia (en
caso de LAN).
DRBD en su versión actual está restringido a un conjunto de dos nodos. Por lo tanto, los clusters
de Alta Disponibilidad con almacenamiento replicado basado en DRBD tienen exactamente dos nodos
(aunque cada nodo puede tener configurados diferentes recursos DRBD y pertenecer a varios clusters,
o los recursos pueden ser apilados (stacked)).

Recursos DRBD
Un recurso (resource) DRBD es un conjunto replicado de unidades de almacenamiento. Puede alojar
uno o múltiples volúmenes (volume). Cada volumen dentro de un recurso puede tener algunos atributos
propios y diferentes de los demás en el mismo recurso. Cada volumen DRBD necesita un espacio de
almacenamiento propio, y ofrecerá un dispositivo de bloques independiente. La administración de DRBD
se realiza al nivel de recursos.

Configuración de DRBD
La configuración de DRBD puede alojarse en /etc/drbd.conf con la descripción de los recursos, o bien
se pueden crear archivos de configuración independientes para cada recurso (dentro de /etc/drbd.d/,
con la extensión .res). En /usr/share/doc/drbd84-utils-8.9.1/drbd.conf.example se encuen-
tra un ejemplo bastante complejo de configuración con varios recursos (ver Apéndice ??).

La configuración de DRBD debe ser idéntica en ambos nodos. Sin embargo, no hay res-
tricciones sobre los nombres o tipos de los dispositivos de soporte. Un volumen puede estar
soportado por particiones de nombre diferente, por una partición en un nodo y por un LV en
el otro, etc.

Ejemplos de configuración
 Un recurso con un único volumen. En ambos hosts, el almacenamiento es idéntico (se utilizan
particiones con el mismo nombre en ambos nodos).

resource drbd0 {
device /dev/drbd0;
disk /dev/sdc2;
meta-disk internal;
on nodo1 {
address 10.0.16.12:7780;
}
on nodo2 {
address 10.0.16.13:7780;
}
}

39
Configuración de DRBD 3 DRBD

 Un recurso con dos volúmenes, con almacenamiento en volúmenes lógicos llamados lv0 y lv1
respectivamente. En ambos nodos, los nombres de los LV son idénticos. Cada volumen recibe un
nombre de dispositivo propio (parámetro device).

resource drbd0 {
net {
protocol A;
}
volume 0 {
device /dev/drbd0;
disk /dev/vgdrbd/lv0;
meta-disk internal;
}
volume 1 {
device /dev/drbd1;
disk /dev/vgdrbd/lv1;
meta-disk internal;
}
on nodo1 {
address 192.168.47.1:7780;
}
on nodo2 {
address 192.168.47.2:7780;
}
}

 Una configuración con un único volumen pero donde los nombres de las particiones de soporte no
son iguales en ambos nodos.

resource drbd0 {
on nodo1 {
device /dev/drbd0;
disk /dev/sdc1;
meta-disk internal;
address 10.0.16.17:7780;
}
on nodo2 {
device /dev/drbd0;
disk /dev/sdb2;
meta-disk internal;
address 10.0.16.16:7780;
}
}

Parámetros de configuración
Discutiremos algunos parámetros importantes de la configuración.
Dispositivo (device) Es el nombre con el que se manejará el volumen usando los comandos adminis-
trativos.
Disco (disk) Es el nombre de dispositivo usual del almacenamiento para ese volumen.
Recursos y volúmenes (resource, volume) La unidad de replicación y de administración es el recurso,
que puede ser dividido en volúmenes que se utilizan independientemente.

40
Configuración de DRBD 3 DRBD

drbdadm cstate Listar estado de conexiones

drbdadm dstate Listar estado de datos
drbdadm up Activar recurso
drbdadm up all Activar todo
drbdadm down all Desactivar todos los recursos
drbdadm primary Asumir el rol primario sobre un recurso
drbd-overview Estado de conexiones y recursos
cat /proc/drbd Monitorear estado de dispositivos

Cuadro 3: Comandos de administración de DRBD

Direcciones (address) Se especificarán las direcciones de cada nodo sobre la red privada, dedicada a
la replicación. La política de firewalling debe permitir la conexión entre los nodos mediante los
ports declarados en la configuración. Como normalmente se trata de una red dedicada, suele ser
conveniente desactivar completamente el firewall sobre esta red.
Metadatos (meta-disk) Los metadatos mantenidos por DRBD durante la operación incluyen datos
vitales para la integridad del volumen y su recuperación. El parámetro de configuración DRBD
correspondiente se llama meta-disk. Pueden ser alojados de dos maneras:
1. En los últimos sectores del mismo soporte del almacenamiento (opción llamada meta-disk
internal)
2. Usando un soporte separado (como, por ejemplo, meta-disk /dev/sdbX ).
La ventaja de la primera opción es una más fácil administrabilidad, ya que los metadatos acompa-
ñan a los datos cada vez que se recuperan. La ventaja de la segunda opción puede explotarse si se
trata de particiones o volúmenes en discos separados, en cuyo caso la performance puede ser mejor
que si datos y metadatos comparten un disco. En caso de altos niveles de actividad los metadatos
pueden convertirse en un cuello de botella, y con la segunda opción esto puede evitarse.
Si se desea instalar DRBD para replicar un volumen de datos preexistente, la primera opción implica
riesgo de corrupción de los datos, a menos que se reduzca el filesystem o se extienda el volumen.
En cualquier otro caso, por simplicidad, la opción más recomendada es meta-disk internal.
Nombres de nodo (on) En la configuración aparecen los nombres de nodo arbitrarios nodo1 y nodo2.
Los nombres de los nodos son vitales tanto para que el software de dispositivos replicados interprete
su configuración, como a los efectos de que los nodos puedan identificarse ante un manejador de
pertenencia al cluster. Deben satisfacerse algunas condiciones indispensables sobre los nombres
para lograr la conexión entre peers.
1. Ambos peers deben responder al comando uname -n con esos respectivos nombres. Para
esto se puede usar temporariamente el comando hostname, pero la configuración persistente
depende de la distribución6 .
2. Cada peer debe poder efectuar la resolución de la dirección del otro por su nombre. Se puede
utilizar un servidor DNS, pero es suficiente con modificar la configuración del resolver local
(/etc/hosts).
Protocolos (protocol) Dependiendo de las características de la red, es posible configurar el dispositivo
replicado para que las operaciones de escritura sean confirmadas al llegar al otro nodo (protocolo
A), al ingresar en la cache del sistema de E/S del otro nodo (protocolo B), o al ser grabadas
físicamente (protocolo C). En redes locales se elige normalmente el protocolo de replicación C,
que es el de mejor integridad de datos, ya que considera efectuada la operación de write solamente
cuando el nodo remoto acusa haber grabado físicamente un sector replicado. En redes con alta
latencia, en cambio, se preferiría el protocolo A.
La configuración por defecto del protocolo (C) se encuentra en el archivo de configuración global.
6
En CentOS se consigue configurando HOSTNAME=nombre en /etc/sysconfig/network.

41
Ejecución de DRBD 3 DRBD

Ejecución de DRBD
Una vez creada la configuración, para la inicialización, puesta en marcha y administración de DRBD
se recurre principalmente al comando drbdadm con sus subcomandos (Cuadro 3).

Inicializar el dispositivo
Esta operación crea en el soporte los metadatos para la replicación.

drbdadm create-md <recurso>

Activar el recurso

drbdadm up <recurso>

Establecer roles
Una vez configurado un recurso y activado por primera vez el dispositivo DRBD, los peers se co-
munican pero no pueden decidir por sí solos cuál de los dos será el primario. El administrador debe
imponer los roles con una opción especial del comando drbdadm. Esta opción varía según las versiones
de DRBD. En DRBD 8.4 en adelante, el rol primario se define únicamente en el nodo que vaya a
cumplir el rol primario dando el comando drbdadm primary --force <recurso>. Esta novedad se
comunica automáticamente al otro peer que se asumirá como secundario y quedará replicando.

Uso del dispositivo

Creación de filesystems
Una vez puesto en marcha exitosamente un dispositivo, ya puede ser utilizado (en el primario)
aunque los peers no hayan acabado la sincronización. Normalmente se creará un filesystem sobre cada
volumen DRBD. Por defecto, mkfs aprovechará todo el espacio en el volumen.

mkfs -t ext4 /dev/drbd0

Notar que el dispositivo donde se crea el filesystem es el especificado como device en la con-
figuración. Los volúmenes o particiones subyacentes no deben volver a accederse mientras
esté activo el dispositivo, ya que son de uso exclusivo del driver DRBD.

Cada filesystem debe ser creado, no sobre el dispositivo de bloques soporte (la partición del disco
/dev/sdaX, el dispositivo RAID /dev/mdX, el volumen /dev/vgX/lvX, etc.), sino sobre el dispositivo
replicado /dev/drbd0, /dev/drbd1, etc., correspondiente, que existe una vez que se ha inicializado el
recurso drbd. DRBD además ofrece un directorio /dev/drbd/by-res donde aparecen subdirectorios por
cada recurso y pseudoarchivos por cada volumen. Alternativamente, se puede usar esa nomenclatura.

Tuning del filesystem

Normalmente un filesystem tiene definido un intervalo de tiempo entre filesystem checks y la cantidad
máxima de veces que se montará el filesystem sin ser chequeado. Cada vez que sea montado el filesystem,
el sistema verificará estas condiciones y eventualmente lanzará un chequeo que puede aumentar la
latencia de la puesta en servicio del nodo. Al crear el filesystem sobre el dispositivo DRBD correspondiente
(con el utilitario mkfs), puede ser de interés redefinir estos parámetros con el utilitario tune2fs. Los
argumentos -c0 y -i0 eliminan esos controles.

tune2fs -c 0 -i 0 /dev/drbd0

42
Monitoreo de DRBD 3 DRBD

Montado de los recursos

En cada nodo se necesitará preparar líneas en /etc/fstab para permitir el montado de los disposi-
tivos de DRBD. Sin embargo, estos dispositivos no deben ser montados automáticamente (opción
noauto) ya que es el servicio de cluster resource manager quien debe manejar su montado y desmontado
en función del rol del nodo dentro del cluster en cada momento.

/dev/drbd0 /public ext3 defaults,noauto 0 0

Failover manual
En ausencia de un gestor de recursos de cluster, y ante cualquier evento de fallo (o para realizar
alguna tarea administrativa), para transferir el rol primario al otro nodo se deben seguir pasos en cierto
orden.
1. En el primario, si está activo, detener las aplicaciones que usen el recurso y desmontarlo.
2. Degradarlo administrativamente al rol secundario. Momentáneamente ambos nodos quedarán en
rol secundario.
3. Promover el otro nodo a primario.
4. Montar el recurso en el nuevo primario.

umount /dev/drbd/by-res/<recurso>
drbdadm secondary <recurso>
drbdadm primary <recurso>
mount /dev/drbd/by-res/<recurso> <punto de montado>

Monitoreo de DRBD
El estado de los recursos se visualiza rápidamente con drbd-overview.

# drbd-overview
0:drbd0/0 Connected Primary/Secondary UpToDate/UpToDate /r0 ext4 19G 173M 18G 1 %
1:drbd0/1 Connected Primary/Secondary UpToDate/UpToDate /r1 ext4 13G 161M 12G 2 %

La información de estado de DRBD incluye una terna de rótulos (cs, ro, ds) con varios posibles
valores:
Connection status (cs) Indica si ambos nodos están conectados. Los valores posibles pueden indicar
estados de esperando conexión, desconectado, en proceso de sincronización, etc. El valor para el
estado correcto operativo es Connected.
Role (ro) Es un par de valores que indican los roles asumidos por ambos nodos en un momento dado.
El primer valor corresponde al nodo donde se da el comando, y el segundo al nodo restante. Los
valores para el estado correcto operativo son Primary/Secondary (cuando el comando se da en el
nodo primario) o Secondary/Primary (cuando se da en el nodo secundario).
Disk Status (ds) Es un valor que indica si los contenidos del almacenamiento de ambos nodos están
sincronizados. El primer valor corresponde al nodo donde se da el comando, y el segundo al nodo
restante. El valor correcto operativo es UpToDate para ambos nodos.
Valores diferentes de los correctos operativos, no necesariamente indican un error, sino que puede
tratarse de una condición transitoria. Inicialmente los dispositivos atravesarán estados de no conectado,
inconsistente, desconocido, etc., hasta que se comuniquen los peers y comiencen a sincronizar sus
contenidos. Otro tanto ocurre durante la recuperación del cluster al volver del modo degradado.

43
Restricciones importantes 3 DRBD

Eventualmente, las ternas de estado de DRBD en ambos nodos deben alcanzar respectivamente
los valores (Connected, Primary/Secondary, UpToDate/UpToDate) y (Connected, Secondary/Primary,
UpToDate/UpToDate).
Para vigilar la actividad de DRBD puede observarse el pseudoarchivo /proc/drbd. Con el comando
watch cat /proc/drbd se puede visualizar constantemente el estado de los recursos. El resto de los
datos que aparecen en la salida corresponde a niveles de performance e historia de actividad.
 Primario, con ambos recursos sincronizados

0: cs:Connected ro:Primary/Secondary ds:UpToDate/UpToDate A r-----

ns:5066100 nr:0 dw:0 dr:5066764 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f
oos:0
1: cs:Connected ro:Primary/Secondary ds:UpToDate/UpToDate A r-----
ns:0 nr:0 dw:0 dr:664 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:0

 Secundario, esperando conexión

0: cs:WFConnection ro:Secondary/Unknown ds:Inconsistent/DUnknown C r----s

ns:0 nr:0 dw:0 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:20127092
1: cs:WFConnection ro:Secondary/Unknown ds:Inconsistent/DUnknown C r----s
ns:0 nr:0 dw:0 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:13422144

 Secundario sincronizando el volumen 0 y habiendo sincronizado el volumen 1

0: cs:SyncTarget ro:Secondary/Primary ds:Inconsistent/UpToDate A r-----

ns:0 nr:4030816 dw:4030816 dr:0 al:0 bm:0 lo:1 pe:7 ua:0 ap:0 ep:1 wo:f
oos:1035284
[==============>.....] sync’ed: 79.7 % (1008/4944)M
finish: 0:03:21 speed: 5,124 (5,380) want: 7,600 K/sec
1: cs:Connected ro:Secondary/Primary ds:UpToDate/UpToDate A r-----
ns:0 nr:0 dw:0 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:0

 Secundario con ambos recursos sincronizados

0: cs:Connected ro:Secondary/Primary ds:UpToDate/UpToDate A r-----

ns:0 nr:5066100 dw:5066100 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f
oos:0
1: cs:Connected ro:Secondary/Primary ds:UpToDate/UpToDate A r-----
ns:0 nr:0 dw:0 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:0

Restricciones importantes
 Bajo ningún concepto debe montarse un filesystem soportado por DRBD v.0.7.X en un nodo
mientras su rol de DRBD es secundario, ni siquiera en modo read-only. El acceso simultáneo es
causa de corrupción de datos.
 La restricción anterior deja de tener efecto a partir de la versión 8.X, que es capaz de funcionar
con ambos nodos en rol primario. Sin embargo, su uso práctico no es trivial porque requiere 1) un
filesystem de cluster y 2) aplicaciones tolerantes al acceso múltiple.

Referencias
 http://www.drbd.org/users-guide-8.4/drbd-users-guide.html

44
Notas de instalación 3 DRBD

Notas de instalación
En la familia RedHat/CentOS es necesaria la instalación previa de un repositorio adicional. Actual-
mente están disponibles paquetes para dos versiones diferentes de DRBD.

rpm --import https://www.elrepo.org/RPM-GPG-KEY-elrepo.org

rpm -Uvh http://www.elrepo.org/elrepo-release-6-6.el6.elrepo.noarch.rpm
yum install drbd84-utils.x86_64 kmod-drbd84.x86_64

Temas de práctica
1. Prepare dos equipos en las condiciones necesarias para formar parte de un cluster de almacenamien-
to replicado DRBD (nombres de nodos, direcciones secundarias, resolución de nombres, partición
libre en un disco, recurso DRBD, /etc/fstab, punto de montado). Busque la configuración DRBD
más simple posible, con un único volumen. Luego de activar el recurso, cree un filesystem sobre él
y observe la sincronización mientras ocurre. Monte y utilice el filesystem. Observe la conducta del
nodo peer cuando se baja administrativamente el recurso, cuando se baja el nodo primario, cuando
se simula una caída del sistema primario, cuando se migra administrativamente el rol primario.
Intente acceder a los archivos creados en el otro nodo. ¿Qué ocurre al recuperarse el nodo ante-
riormente perdido? Tenga en cuenta que, en este ejercicio, las acciones de montar y desmontar
los filesystems son manuales.
2. Idem anterior, pero creando un LV sobre el recurso DRBD.
3. Investigue la opción de configuración dual-primary de DRBD. Con esta opción, ¿qué ocurrirá si
se monta el recurso en ambos nodos, sin contar con un filesystem de cluster? ¿Qué ocurrirá si se
interrumpe la comunicación por la red entre los nodos?
4. En un cluster dual-primary, ¿puede utilizar el mecanismo de snapshots de LVM para acceder a los
contenidos del LV desde el otro nodo sin migrar el primario?
5. Discuta qué mecanismos serían necesarios para que las operaciones de asumir el rol primario, y
montar/desmontar los recursos DRBD, fueran automáticas, y cómo se podrían implementar.
6. La robustez del sistema DRBD depende de la estabilidad de las comunicaciones a través de la red.
Investigue sobre el fenómeno de split brain, qué significa, sus causas, su gravedad, y las formas de
resolverlo.
7. ¿Cómo se puede producir una situación de split brain en el cluster de práctica? ¿Cuál es la conducta
del sistema ante este evento?

45
 1 VIRTUALIZACIÓN

Parte V
Virtualización
1. Virtualización
Concepto
Hablamos de software que implementa abstracciones de recursos computacionales físicos o lógicos,
mediante el cuál un mismo recurso base (servidor, sistema operativo, storage, red, etc.) puede actuar
como múltiples recursos lógicos o virtuales.
Es así, por ejemplo, que una misma interfaz de red puede virtualizarce para acceder a redes diferentes
a través de la misma interfaz física. O bien, un archivo en un sistema de archivos puede ser utilizado
como si fuese un nuevo disco físico a a través de ciertos mecanismos.
Vemos entonces que la virtualización se aplica diferentes niveles, en particular, y para los fines de
esta materia, nos referiremos a conceptos e implementaciones, que permiten que una misma compu-
tadora física pueda actuar como múltiples computadoras simultáneamente, esto es Virtualización de
plataforma

Arquitectura y terminología
Se presenta a continuación una estructura general de cómo se implementan las distintas formas de
virtualización de plataforma desarrolladas mas adelante, más la terminología necesaria para compren-
derlas.
 Hardware del servidor se refiere a uno o más servidores físicos sobre los que aplicaremos métodos
de virtualización. Sobre éste será instalada y configurada una herramienta para virtualización, y
aportará todos los recursos de hardware, de los que harán uso las máquinas virtuales. 7
 Capa de virtualización. Es el elemento virtualizador y, dependiendo de la solución de virtualización
escogida, la capa estará ubicada de forma diferente. Así es posible que ésta se encuentre integrada
con el sistema operativo que controla el hardware del servidor; que sea una aplicación en el área de
usuario que es ejecutada sobre un sistema operativo (como cualquier otra aplicación); o bien una
capa que corre directamente sobre el hardware del servidor, como es el caso de los hipervisores.
Sin esta capa, el sistema operativo se comunica directamente con el hardware subyacente. Esto es,
las operaciones sobre discos, irán directamente al subsistema de discos, las llamadas a memoria
serán tomadas directamente por la memoria física, etc. Sin esta capa, sería imposible y caótico
que múltiples sistemas operativos simultáneos, de diferentes máquinas virtuales, accedan a dichos
recursos de manera ordenada. Es así que la capa de virtualización administra las interacciones entre
cada máquina virtual individual y el hardware que todas ellas comparten
El término utilizado normalmente para el software que implementa esta capa de virtualización es
Hipervisor8 o Monitor de máquina virtual.
 Hipervisor o Monitor de máquina virtual: diferenciamos entre dos tipos de hipervisores.
 Tipo 1
◦ Se ejecuta directamente sobre el hardware y lo controla en favor de las máquinas virtuales.

◦ Usualmente referido como implementación Bare-Metal.

◦ En comparación con los hipervisores de tipo 2, se considera que este tipo de implemen-
taciones presenta mejor rendimiento y aislamiento de las máquinas virtuales. Así como
también menor sobrecarga de procesamiento.
◦ Xen, VMware ESX/ESXi, Hyper-V, Oracle VM Server

 Tipo 2
7
Más adelante distinguiremos entre estas y el término container
8
El término hipervisor fue acuñado en un momento en el que los sistemas operativos eran referidos como supervisores,
dando lugar a un elemento que supercede a estos últimos.

46
Tipos de virtualización de plataforma 1 VIRTUALIZACIÓN

◦ En este caso el hipervisor será una aplicación que se ejecuta sobre un sistema operativo
tradicional. Este último será el encargado de administrar el hardware,
◦ Son más sencillos de instalar y configurar, ya que usualmente toda la configuración
específica del hardware fue realizada a nivel del sistema operativo sobre el que reside.
◦ Están disponibles para un mayor espectro de arquitecturas de hardware, por ser ésta

controlada por un sistema operativo de propósito general.

◦ Menos eficientes, pues los pedidos de acceso al hardware pasan de la máquina virtual al
hipervisor, y de éste al sistema operativo (ídem para el camino inverso).
◦ VMware Workstation, VirtualBox, KVM

 Máquinas virtuales. Serán el elemento final de la arquitectura a ser utilizado por los usuarios (a
través de las aplicaciones) de la plataforma. Administradas en su ciclo de vida, esto es creadas,
configuradas, encendidas/apagadas, y monitorizadas, por la capa de virtualización. Nos permiten
dar la sensación de tener múltiples equipos independientes sobre un mismo hardware. Cada una de
ellas, disponen de su propio hardware de forma virtual (ya sea real o emulado), su propia instancia
de un sistema operativo y, siendo el aspecto más interesante, ejecutan sus propias aplicaciones de
manera aislada del resto del entorno, como si se tratara de una computadora física real individual.
Podremos tener tantas máquinas virtuales como el hardware permita.
 Hosts o Anfitriones: nos referimos a la computadora que ejecuta el software que gestionan los
recursos y administra las máquinas virtuales.
 Guests o Huéspedes: máquinas virtuales o containers.

Tipos de virtualización de plataforma

En esta sección analizaremos algunas generalidades sobre las innumerables implementaciones de
hipervisores que existen actualmente. El objetivo será comprender que existen diferencias entre dichos
hipervisores, dependiendo del o los objetivos para los cuales fueron creados. Comprender esta diversidad,
permite al administrador o administradora de sistemas, decidir y utilizar tecnologías de virtualización de
manera óptima. Tener noción de qué podemos esperar de dicha tecnología, cuáles son sus objetivos de
diseño fundamentales y qué no esperar de la misma.
 Virtualización asistida por hardware
 Apoyo provisto por el hardware para facilitar las tareas de virtualización.

 Los procesadores de arquitectura x86 fueron diseñados pensando en un sólo sistema operativo
por computadora, a diferencia de los grandes mainframes en los que desde su diseño se
necesitaban mecanismos para compartir grandes cantidades de recursos de hardware. Esto
hizo que la incorporación de virtualización con buen rendimiento en arquitecturas x86, no
viera la luz sino hasta alrededor del año 2006, en donde distintos fabricantes de procesadores
incorporaron características de asistencia a la tarea de virtualización.
 Esta caracterísitca suele habilitarse y deshabilitarse desde el firmware que controla el arran-
que de la computadora (BIOS, UEFI, etc.), y puede verificarse desde el sistema operativo
observando los flags del procesador: ver salida de archivo /proc/cpuinfo.
 VMWare, QEMU, KVM, Xen

 Virtualización completa o Emulación

 Reproducción, mediante software, de la conducta de todo el hardware. Es necesario escribir
emuladores para cada dispositivo, lo cual es laborioso, costoso y generalmente difícil; pero
presenta la ventaja de que la máquina completamente emulada permite correr cualquier
sistema operativo sin modificaciones y sin que ese sistema operativo, ni las aplicaciones,
perciban que están corriendo sobre hardware emulado. Esta forma de virtualización presenta
la mayor fidelidad y transparencia, pero performance limitada.
 Paravirtualización
 En este caso se instrumentan cambios tanto en el sistema operativo anfitrión, como en el
húesped. Este último no podrá ejecutarse directamente sobre el hardware desnudo (bare-
metal).

47
 2 APLICACIONES

 Reescritura de los drivers del sistema operativo host y de los guests. Los drivers se construyen
según el modelo de split drivers, o drivers divididos. El sistema operativo host es quien sigue
actuando, con la parte inferior de los drivers, sobre los dispositivos físicos. Las máquinas
virtuales, al efectuarse un requerimiento de entrada/salida, activan la mitad superior del
driver y provocan un trap al monitor de virtualización, que administra los pedidos y los
deriva a la mitad inferior del driver. Los nuevos drivers permiten multiplexar entrada/salida
entre los dispositivos físicos y una cantidad de dispositivos virtuales asociados. La ventaja
principal es la gran performance lograda con respecto a la emulación o virtualización completa.
Para determinadas cargas de trabajo, especialmente para programas acotados por CPU, la
eficiencia de un conjunto de máquinas paravirtualizadas es muy cercana al óptimo. La principal
desventaja es que claramente se necesita modificar o instrumentar el código, tanto del sistema
operativo host como de los guests. Sin embargo las aplicaciones siguen funcionando sin
modificaciones.
 Xen

 Virtualización a nivel del SO

 Creación de múltiples espacios de usuario independientes en lugar de uno solo (llamados,
según la tecnología específica, contenedores, virtual engines o VEs, virtual private servers
o VPS, o jails). Permiten al usuario y a las aplicaciones obtener la misma vista que si se
tratara de un server real. Implementación avanzada del mecanismo de chroot. El kernel ofrece
características de administración de recursos para garantizar el uso equitativo de los mismos
entre los contenedores.
 VServer, OpenVZ, LXC, Docker En un container podríamos (aunque no necesariamente)
hacer ssh, obtener un shell; tiene su propio conjunto de procesos y usuarios; instalar paquetes;
ejecutar cosas como root, etc. A diferencia de una vm, comparte el kernel con el host; no
puede tener módulos propios; no requiere de un init con PID 1; no requiere de syslog, cron,
etc. El objetivo es ejecutar alguna/s aplicación/es con todas sus dependencias y necesidades
PERO NADA MAS. . . de ahí su pequeño tamaño. En Linux hay soporte en el kernel: man
namespaces Pueden contener sistemas operativos distintos, sin embargo la arquitectura y
el kernel están determinadas por el anfitrión. Su tamaño y consumo de recursos suele ser
ampliamente inferior a una vm completa. La velocidad de inicio de ejecución de un container
es mucho más veloz que la de una vm completa.

2. Aplicaciones
 Para el usuario final
 Revolución del multicore

◦ Muchos equipos en uno

 Probar nuevas distribuciones u otro software

 Probar actualizaciones

 Para el administrador de sistemas

 Independencia del hardware

 Sistemas legacy

 Provisioning

 Live Migration y balance de carga

 Validación de backups, staging

 Hosting de servicios

 Consolidación de servidores

◦ Menos espacio

◦ Menos consumo de energía

◦ Menos calor disipado

 Aumentar la disponibilidad

48